Я вивчав SSRS 2005/2008 протягом останніх тижнів і створив кілька звітів на стороні сервера. Щодо програми, колега запропонував мені вивчити RDLC для конкретної ситуації. Зараз я намагаюся обернути голову навколо основної різниці між RDL та RDLC.

Пошук цієї інформації дає в кращому випадку фрагментарну інформацію. Я дізнався, що:

• Звіти RDLC не зберігають інформацію про те, як отримати дані.
• Звіти RDLC можуть виконуватися безпосередньо контролем ReportViewer.

Але я все ще не повністю розумію зв’язок між файлом RDLC та іншими пов'язаними системами (сервер звітування, база даних джерела, клієнт).

Щоб добре зрозуміти файли RDLC, я хотів би знати, чим їх використання відрізняється від RDL-файлів і в якій ситуації вибиратимуть RDLC над RDL. Посилання на ресурси також вітаються.

Оновлення:

Нитка на форумах ASP.NET обговорює це ж питання. З цього я отримав трохи кращого розуміння цього питання.

Особливістю RDLC є те, що він може запускатися повністю на стороні клієнта в елементі управління ReportViewer.

• Це знімає потребу в екземплярі служб Reporting Services і навіть усуває потребу в будь-якому підключенні до бази даних, але:
• Він додає вимогу, що дані, необхідні у звіті, повинні надаватися вручну.

Переважно це чи недолік, залежить від конкретного застосування.

У моїй програмі екземпляр Служб звітування доступний у будь-якому випадку, і необхідні дані для звітів можна легко витягти з бази даних. Чи залишається мені якась причина для розгляду RDLC, або я просто дотримуюся RDL?

З мого досвіду можна подумати над обома речами:

I. Звіти RDL - це звіти HOSTED. Це означає, що вам потрібно впровадити SSRS-сервер. Вони є вбудованим розширенням Visual Studio від SQL Server для мови звітування. Під час встановлення SSRS вам слід мати додаток під назвою "Студія розвитку бізнес-аналітики", що працювати зі звітами набагато простіше, ніж без нього.

Р епорт

D закінчення

L angauge

Переваги звітів RDL:

1. Ви можете розміщувати звіти в середовищі, де на них працюють служби.
2. Ви можете налаштувати безпеку на елементі або рівні спадкування, щоб обробляти безпеку як окрему концепцію
3. Ви можете налаштувати службу для надсилання електронних листів (за умови, що у вас є SMTP-сервер, до якого ви маєте доступ) та зберігати файли за розкладом
4. У вас є база даних, яка зазвичай називається "ReportServer", і ви можете запитувати інформацію про опубліковані звіти.
5. Ви можете отримати доступ до цих звітів, як і раніше, через "ReportViewer" у клієнтській програмі, написаній на ASP.NET, WPF (з відміткою керування Winform!) Або Winforms в .NET, використовуючи "ProcessingMode.Remote".
6. Ви можете встановити параметри, які користувач може бачити та використовувати для отримання більшої гнучкості.
7. Ви можете налаштувати частини звіту, які будуть використовуватися для рядків з'єднання як "Джерела даних", а також sql-запиту, xml або інших наборів даних як "Набір даних". Ці частини та інші можна регулярно зберігати та конфігурувати для кешування даних.
8. Ви можете записати .NET проксі-класи служб http: // / ReportServer / ReportingService2010 або / ReportExecution2005. Потім ви можете створити свої власні методи у .NET для надсилання електронної пошти, збереження чи маніпулювання даними SSRS із служби безпосередньо сервера, що розміщує звіти SSRS у коді. Програмно експортувати звіт SSRS з точки огляду, використовуючи ReportService2010.asmx

Недоліки:

1. SSRS - це різновид winkey порівняно з іншими речами, коли швидко вставати. Більшість людей плутають політику безпеки та розробляють звіти як "доповнення" до VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. Продовжуючи 1, політика щодо налаштувань безпеки IMHO ідіотично перевиконана. На сторінці розміщена безпека сервера, захист бази даних та ролі, два параметри безпеки. Більшість людей налаштовують лише адміністратора, ніж не можуть зайти, і дивуються, чому інші користувачі не можуть. Найпоширеніша скарга чи запитання щодо SSRS пов'язані із тим, що я, як правило, звертаюся зі свого досвіду.
3. Ви можете використовувати "вирази", які, мабуть, "покращать" ваш звіт. Часто ви робите більше декількох, і ваш звіт приходить до сканування продуктивності.
4. У вас є певна кількість речей, які ви можете зробити та експортувати. У SSRS немає наведення курсора на звітування, про яке я знаю, без злому javascript.
5. Швидкість і продуктивність можуть вразити, коли дурна конфігурація SSRS переробляє систему, і перший звіт може зайняти деякий час, просто завантажуючи сайт. Ви можете подолати це, змінивши його, але я знайшов, щоб зробити підтримку в живих, щоб вона працювала краще.

II. Звіти RDLC - це звіти, які містять КЛІЄНТ, які НЕ БУДЬ БУДІТЬСЯ. Додатковий c у назві означає "Клієнт". Як правило, це розширення мови RDL, призначеного для використання лише у клієнтських додатках Visual Studio. Він існує у Visual Studio, коли ви додаєте елемент "звітування".

Переваги звітів RDLC:

1. Ви можете підключити послугу wcf набагато набагато простіше до набору даних.
2. Ви маєте більше контролю над набором даних і можете використовувати класи POCO, заповнені об'єктами Entity Framework або ADO.NET безпосередньо, а також самими таблицями. Ви можете мавпати з даними для їх оптимізації перед прив’язкою до звіту.
3. Ви можете налаштувати зовнішній вигляд, додавши до нього прямо в коді позаду.

Недоліки:

1. Вам потрібно обробляти параметри самостійно, і тоді як ви можете реалізувати методи обгортки, щоб допомогти обробці нігтів - трохи більше, ніж очікувалося і прикро.
2. Користувач не може бачити параметри в контролі "ReportViewer", якщо він не знаходиться у віддаленому режимі та не має доступу до звіту RLD. Таким чином, вам потрібно зробити текстові поля, спадні місця, радіо кнопки самостійно поза контролем, щоб перейти до нього. Деяким людям це додало контролю, я не особисто.
3. Все, що ви хочете зробити із обслуговування звітів для розповсюдження, вам потрібно створити самостійно. Електронна пошта, підписки, економія. Вибачте, що вам потрібно створити це в .NET або ж іншим чином реалізувати проксі-сервер, який вже робить це зверху, ви можете просто використовувати розміщені звіти.

Чесно кажучи, я люблю обидва для різних цілей. Якщо я хочу щось вийти аналітикам, що вони весь час використовують і налаштовують на графіки, діаграми, скорочення та експорт до Excel, я використовую RDL і просто на сайті SSRS виконується вся робота з обробки електронних розсилок. Якщо я хочу, щоб програма, в якій є розділ звітів, і знаю, що програма - це власний модуль з правилами та управлінням, я використовую RDLC, параметри якого мають бути меншими, і керуються рішеннями, прийнятими користувачем, перш ніж потрапити на частину звіту клієнта, на якому вони є і на сайті, і тоді вони зазвичай просто вибирають часові рамки або тип і нічого більше. Таким чином, як правило, складний звіт я б використовував RDL, а для чогось простого я використовував би RDLC IMHO.

Я сподіваюся, що це допомагає.

Питання: Чим відрізняються формати RDL від RDLC?

Відповідь: Файли RDL створюються версією конструктора звітів SQL Server 2005 версії. Файли RDLC створюються версією Visual Studio 2008 версії дизайнера звітів.

Формати RDL і RDLC мають однакову схему XML. Однак у файлах RDLC деякі значення (наприклад, текст запиту) можуть бути порожніми, це означає, що вони не одразу готові до публікації на сервері звітів. Пропущені значення можна ввести, відкривши файл RDLC за допомогою версії SQL Server 2005 версії конструктора звітів. (Ви повинні перейменувати .rdlc у .rdl спочатку.)

Файли RDL повністю сумісні з режимом виконання ReportViewer. Однак файли RDL не містять певної інформації, від якої залежить час проектування контролю ReportViewer для автоматичного генерування коду, що зв'язує дані. Вручну зв'язуючи дані, RDL-файли можна використовувати в елементі управління ReportViewer. Новий! Дивіться також зразок програми перегляду RDL.

Зауважте, що елемент управління ReportViewer не містить жодної логіки підключення до баз даних або виконання запитів. Виділяючи таку логіку, ReportViewer став сумісним з усіма джерелами даних, включаючи джерела даних, що не мають бази даних. Однак це означає, що коли файл RDL використовується керуванням ReportViewer, інформація, пов'язана з SQL, у файлі RDL просто ігнорується елементом управління. Відповідальність хост-програми несе відповідальність за підключення до баз даних, виконання запитів та подачу даних до управління ReportViewer у формі ADO.NET DataTables.

http://www.gotreportviewer.com/

Я завжди вважав, що між RDL і RDLC відмінність полягає в тому, що RDL використовуються для служб звітування SQL Server, а RDLC використовуються у Visual Studio для звітування на стороні клієнта. Реалізація та редактор майже однакові. RDL розшифровується як Report Defintion Languageі RDLC Report Definition Language Client-side .

Я сподіваюся, що це допомагає.

З мого досвіду, якщо вам потрібна висока продуктивність (це дуже залежить від специфікацій вашого клієнта) для великих звітів, перейдіть з rdlc. Крім того, звіти rdlc дають вам дуже повний спектр контролю над вашими даними, можливо, ви зможете врятувати себе витраченими відключеннями бази даних тощо, використовуючи звіти клієнтської сторони. У проекті, над яким я зараз працюю, критичний звіт вимагає приблизно 2 хвилини для візуалізації на стороні сервера, і в значній мірі виймає той сервер звітності, який він потрапив за той час. Перемикаючи його на рендеринг на стороні клієнта, ми бачимо продуктивність набагато ближче до 20-40 секунд без навантаження на сервер звітів і меншої пропускної здатності, оскільки використовуються лише набори даних.

Ваш пробіг може відрізнятися, і я знаходжу складність розробки та обслуговування rdlc, особливо коли ваш звіт розроблений як звіт на стороні сервера.

Деякі з цих питань були розглянуті вище, але ось два мої центи для середовища VS2008.

RDL (Віддалені звіти): Набагато кращий досвід розробки, більша гнучкість, якщо вам потрібно використовувати деякі розширені функції, такі як планування, спеціальна звітність тощо.

RDLC (Місцеві звіти): кращий контроль над даними, перш ніж надсилати їх у звіт (простіше перевірити або маніпулювати даними перед тим, як надсилати їх у звіт). Набагато простіше розгортання, немає необхідності в екземплярі служб Reporting Services.

ОГРОМНИЙ застереження з місцевими звітами - відомий витік пам’яті, який може серйозно вплинути на продуктивність, якщо ваші клієнти будуть мати численні великі звіти. Це має бути вирішено у новій версії програми перегляду звітів VS2010.

У моєму випадку, оскільки у нас є екземпляр Служб звітування, я розробляю нові звіти як RDL, а потім конвертую їх у локальні звіти (що легко) і розгортаю їх як місцеві звіти.

Якщо у вас є доступна інфраструктура служб звітності, використовуйте її. Ви знайдете розробку RDL трохи приємніше. Ви можете попередньо переглянути звіт, легко налаштувати параметри тощо.

Хоча в даний час я схиляюся до RDL, оскільки він здається більш гнучким і легшим в управлінні, RDLC має перевагу в тому, що він, схоже, спрощує ваше ліцензування. Оскільки RDLC не потребує екземпляра служб Reporting Services, для його використання вам не знадобиться Ліцензія служб Reporting Services.

Я не впевнений, чи все ще це стосується новіших версій SQL Server, але свого часу, якщо ви вирішили розмістити екземпляри бази даних SQL Server та служби звітування на двох окремих машинах, вам потрібно було мати дві окремі ліцензії SQL Server:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Ви можете Bing для інших подібних блогів та публікацій щодо ліцензування служб Reporting Services.

Для VS2008 я вважаю, що RDL надає кращі можливості редагування, ніж RDLC. Наприклад, я можу змінити Bold на вибрану кількість тексту в текстовому полі з RDL, тоді як у RDLC це неможливо.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -or- abcd efgh ijklmnop (єдині ваші варіанти)

Це тому, що RDLC використовує більш ранню область імен / форматування від 2005 року, тоді як RDL використовує 2008 рік. Це, однак, зміниться з VS2010

Якщо у нас є менша кількість звітів, які є менш складними та споживаються веб-сторінками asp.net. Краще йти з rdlc, тому що ми можемо уникати ремонту звітів про екземпляр RS. але ми повинні отримати дані з БД вручну і прив’язати їх до rdlc.

Мінуси: проектувати rdlc у візуальній студії мало складно порівняно з дизайнером SSrs.

Про: Технічне обслуговування просте. під час експорту звіту зі сторінки, ми спостерігали підвищення продуктивності порівняно зі звітами на стороні сервера.

якщо ви хочете використовувати звіт на asp.net, тоді використовуйте .rdl, якщо ви хочете використовувати / переглядати у звіті-конструкторі / сервері звітів, тоді використовуйте .rdlc, просто перетворюючи формат вручну, він працює