Ho studiato SSRS 2005/2008 nelle ultime settimane e ho creato alcuni rapporti lato server. Per alcune applicazioni, un collega mi ha suggerito di esaminare RDLC per quella particolare situazione. Ora sto cercando di capire la principale differenza tra RDL e RDLC.

La ricerca di queste informazioni produce nella migliore delle ipotesi informazioni frammentate. Ho imparato che:

• I rapporti RDLC non memorizzano le informazioni su come ottenere i dati.
• I report RDLC possono essere eseguiti direttamente dal controllo ReportViewer.

Ma ancora non capisco completamente la relazione tra il file RDLC e gli altri sistemi correlati (il Reporting Server, il database di origine, il client).

Per avere una buona conoscenza dei file RDLC, vorrei sapere in che modo il loro utilizzo differisce dai file RDL e in quale situazione si sceglierebbe RDLC su RDL. Anche i collegamenti alle risorse sono i benvenuti.

Aggiornare:

Un thread nei forum ASP.NET discute lo stesso problema. Da ciò ho acquisito una migliore comprensione della questione.

Una caratteristica di RDLC è che può essere eseguito completamente lato client nel controllo ReportViewer.

• Ciò elimina la necessità di un'istanza di Reporting Services e persino elimina la necessità di qualsiasi connessione al database, ma:
• Aggiunge il requisito che i dati necessari nel report debbano essere forniti manualmente.

Se questo è un vantaggio o uno svantaggio dipende dalla particolare applicazione.

Nella mia applicazione è comunque disponibile un'istanza di Reporting Services ei dati richiesti per i report possono essere facilmente estratti da un database. C'è qualche motivo per prendere in considerazione RDLC, o dovrei semplicemente restare con RDL?

Dalla mia esperienza ci sono poche cose a cui pensare su entrambe le cose:

I. I rapporti RDL sono generalmente rapporti OSPITATI. Ciò significa che è necessario implementare il server SSRS. Sono un'estensione incorporata di Visual Studio da SQL Server per il linguaggio di reporting. Quando installi SSRS dovresti avere un componente aggiuntivo chiamato "Business Intelligence Development Studio" che è molto più facile lavorare con i report che senza di esso.

R eport

D efinizione

L angauge

Vantaggi dei report RDL:

1. È possibile ospitare i report in un ambiente che dispone di servizi in esecuzione su di essi.
2. È possibile configurare la sicurezza su un elemento o un livello ereditario per gestire la sicurezza come concetto autonomo
3. È possibile configurare il servizio per inviare e-mail (a condizione che si disponga di un server SMTP a cui si ha accesso) e salvare i file nei programmi
4. Hai un database generalmente chiamato "ReportServer" su cui puoi richiedere informazioni sui rapporti una volta pubblicati.
5. È possibile accedere a questi report ancora tramite "ReportViewer" in un'applicazione client scritta in ASP.NET, WPF (con un controllo winform bleh!) O Winforms in .NET utilizzando "ProcessingMode.Remote".
6. È possibile impostare i parametri che un utente può vedere e utilizzare per ottenere maggiore flessibilità.
7. È possibile configurare parti di un report da utilizzare per le stringhe di connessione come "Origini dati", nonché una query SQL, XML o altri set di dati come "Set di dati". Queste parti e altre possono essere memorizzate e configurate per memorizzare nella cache i dati su base regolare.
8. È possibile scrivere classi proxy .NET dei servizi http: // / ReportServer / ReportingService2010 o / ReportExecution2005. È quindi possibile creare i propri metodi in .NET per inviare tramite posta elettronica, salvare o modificare i dati SSRS dal servizio direttamente da un server che ospita report SSRS nel codice. Esporta a livello di codice il report SSRS da sharepoint utilizzando ReportService2010.asmx

Svantaggi:

1. SSRS è un po 'stupido rispetto ad altre cose su come farlo velocemente. La maggior parte delle persone viene confusa dalla politica di sicurezza e dalla progettazione di report come "aggiunta" a VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. Continuando su 1 la politica per le impostazioni di sicurezza IMHO sono idioticamente troppo complesse. C'è sicurezza del server, sicurezza del database e ruoli, due impostazioni di sicurezza sulla pagina ospitata per il servizio. La maggior parte delle persone configura solo un amministratore che non può entrare e si chiede perché gli altri utenti non possono farlo. La lamentela o la domanda più comune sulla SSRS è correlata all'ingresso in generale dalla mia esperienza.
3. È possibile utilizzare "espressioni" che presumibilmente "miglioreranno" il report. Spesso ne esegui più di alcune e il tuo rapporto subisce una scansione in termini di prestazioni.
4. Hai una serie di cose che puoi fare ed esportare. SSRS non ha il passaggio del mouse sui rapporti che conosco senza un hack javascript.
5. La velocità e le prestazioni possono subire un duro colpo poiché la stupida configurazione di SSRS ricicla il sistema e un primo rapporto può richiedere del tempo a volte solo per caricare il sito. Puoi aggirare questo problema modificandolo, ma ho scoperto che creare un servizio Keep Vive funziona meglio.

II. I rapporti RDLC sono rapporti CONTENUTI DI CLIENTE che NON SONO OSPITATI NESSUNA PARTE. La c in più nel nome significa "Cliente". In genere si tratta di un'estensione del linguaggio RDL destinata all'uso solo nelle applicazioni client di Visual Studio. Esiste in Visual Studio quando aggiungi un elemento di "rapporto".

Vantaggi dei rapporti RDLC:

1. Puoi collegare un servizio wcf molto molto più facilmente al set di dati.
2. Hai un maggiore controllo sul set di dati e puoi utilizzare classi POCO riempite con oggetti Entity framework o ADO.NET direttamente così come le tabelle stesse. È possibile eseguire la scimmia con i dati per ottimizzarli prima di associarli al report.
3. Puoi personalizzare di più l'aspetto con i componenti aggiuntivi direttamente nel codice sottostante.

Svantaggi:

1. Devi gestire i parametri da solo e anche se puoi implementare metodi wrapper per aiutare il legwork è un po 'più del previsto e sfortunato.
2. L'utente non può VEDERE i parametri in un controllo "ReportViewer" a meno che non sia in modalità remota e acceda a un rapporto RLD. Quindi è necessario creare caselle di testo, menu a discesa, pulsanti di opzione fuori dal controllo per passarvi. Ad alcune persone piace questo controllo aggiunto, non personalmente.
3. Tutto ciò che vuoi fare con la manutenzione dei rapporti per la distribuzione devi crearlo da solo. Email, abbonamenti, salvataggio. Spiacente, devi crearlo in .NET oppure implementare un proxy che lo fa già dall'alto, potresti semplicemente ottenere utilizzando i rapporti ospitati.

Onestamente mi piacciono entrambi per scopi diversi. Se voglio qualcosa che vada agli analisti che usano sempre e modificano grafici, grafici, approfondimenti ed esportazioni in Excel, uso RDL e ho solo il sito di SSRS che si occupa di gestire le distribuzioni di posta elettronica. Se desidero un'applicazione che abbia una sezione di report e so che l'applicazione è il suo modulo con regole e governance, utilizzo un RDLC e avendo i parametri più piccoli ed essere guidato dalle decisioni prese dall'utente prima di arrivare alla parte del report di cosa cliente in cui si trovano e poi di solito scelgono solo un periodo di tempo o un tipo e nient'altro. Quindi generalmente un rapporto complesso userei RDL e per qualcosa di semplice userei RDLC IMHO.

Spero che aiuti.

D: Qual è la differenza tra i formati RDL e RDLC?

R: I file RDL vengono creati dalla versione SQL Server 2005 di Report Designer. I file RDLC vengono creati dalla versione Visual Studio 2008 di Report Designer.

I formati RDL e RDLC hanno lo stesso schema XML. Tuttavia, nei file RDLC, alcuni valori (come il testo della query) possono essere vuoti, il che significa che non sono immediatamente pronti per essere pubblicati su un server di report. I valori mancanti possono essere inseriti aprendo il file RDLC utilizzando la versione SQL Server 2005 di Report Designer. (Devi prima rinominare .rdlc in .rdl.)

I file RDL sono completamente compatibili con il runtime di controllo ReportViewer. Tuttavia, i file RDL non contengono alcune informazioni da cui dipende la fase di progettazione del controllo ReportViewer per la generazione automatica del codice di associazione dati. Associando manualmente i dati, i file RDL possono essere utilizzati nel controllo ReportViewer. Nuovo! Vedi anche il programma di esempio RDL Viewer.

Si noti che il controllo ReportViewer non contiene alcuna logica per la connessione ai database o l'esecuzione di query. Separando tale logica, ReportViewer è stato reso compatibile con tutte le origini dati, comprese le origini dati non database. Tuttavia, ciò significa che quando un file RDL viene utilizzato dal controllo ReportViewer, le informazioni relative a SQL nel file RDL vengono semplicemente ignorate dal controllo. È responsabilità dell'applicazione host connettersi ai database, eseguire query e fornire dati al controllo ReportViewer sotto forma di ADO.NET DataTables.

http://www.gotreportviewer.com/

Ho sempre pensato che la differenza tra RDL e RDLC sia che RDL viene utilizzato per SQL Server Reporting Services e RDLC viene utilizzato in Visual Studio per i rapporti lato client. L'implementazione e l'editor sono quasi identici. RDL sta per Report Defintion Languagee RDLC Report Definition Language Client-side .

Spero che aiuti.

Dalla mia esperienza, se hai bisogno di prestazioni elevate (questo dipende leggermente dalle specifiche del tuo cliente) su report di grandi dimensioni, vai con rdlc. Inoltre, i rapporti rdlc ti offrono una gamma molto completa di controllo sui tuoi dati, potresti essere in grado di risparmiare viaggi di database sprecati, ecc. Utilizzando i rapporti lato client. Sul progetto a cui sto attualmente lavorando, un report critico richiede circa 2 minuti per il rendering sul lato server e praticamente elimina qualsiasi server di report che colpisce per quel tempo. Passando al rendering lato client, vediamo prestazioni molto più vicine a 20-40 secondi senza carico sul server di report e meno larghezza di banda utilizzata perché vengono scaricati solo i set di dati.

Il tuo chilometraggio può variare e trovo che rdlc aggiunga complessità di sviluppo e manutenzione, specialmente quando il tuo rapporto è stato progettato come rapporto lato server.

Alcuni di questi punti sono stati affrontati sopra, ma ecco i miei 2 centesimi per l'ambiente VS2008.

RDL (report remoti): esperienza di sviluppo molto migliore, maggiore flessibilità se è necessario utilizzare alcune funzionalità avanzate come la pianificazione, la creazione di report ad-hoc, ecc ...

RDLC (rapporti locali): migliore controllo sui dati prima di inviarli al rapporto (più facile convalidare o manipolare i dati prima di inviarli al rapporto). Implementazione molto più semplice, non è necessaria un'istanza di Reporting Services.

Un enorme avvertimento con i rapporti locali è una nota perdita di memoria che può influire gravemente sulle prestazioni se i tuoi client eseguiranno numerosi rapporti di grandi dimensioni. Questo dovrebbe essere risolto con la nuova versione VS2010 del visualizzatore di report.

Nel mio caso, poiché abbiamo un'istanza di Reporting Services disponibile, sviluppo nuovi report come RDL, quindi li converto in report locali (operazione semplice) e li distribuisco come report locali.

Se disponi di un'infrastruttura di servizi di reportistica, utilizzala. Troverai che lo sviluppo RDL sarà un po 'più piacevole. È possibile visualizzare in anteprima il report, impostare facilmente i parametri, ecc.

Anche se attualmente propendo per RDL perché sembra più flessibile e più facile da gestire, RDLC ha un vantaggio in quanto sembra semplificare la tua licenza. Poiché RDLC non necessita di un'istanza di Reporting Services, non sarà necessaria una licenza di Reporting Services per utilizzarlo.

Non sono sicuro che ciò si applichi ancora alle versioni più recenti di SQL Server, ma contemporaneamente se sceglievi di inserire le istanze del database di SQL Server e di Reporting Services su due macchine separate, dovevi avere due licenze SQL Server separate:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

È possibile Bing per altri blog e post simili relativi alle licenze di Reporting Services.

Per VS2008, credo che RDL offra funzionalità di modifica migliori rispetto a RDLC. Ad esempio, posso modificare il grassetto su una quantità di testo selezionata in una casella di testo con RDL, mentre in RDLC non è possibile.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -oppure- abcd efgh ijklmnop (sono le tue uniche opzioni)

Questo perché RDLC utilizza uno spazio dei nomi / formattazione precedente del 2005, mentre RDL utilizza il 2008. Tuttavia, questo cambierà con VS2010

Se abbiamo un numero inferiore di report che sono meno complessi e consumati dalle pagine Web asp.net. È meglio andare con rdlc, il motivo è che possiamo evitare di mantenere i rapporti sull'istanza RS. ma dobbiamo recuperare i dati dal DB manualmente e collegarli a rdlc.

Contro: progettare rdlc in visual studio è un po 'difficile rispetto a SSrs designer.

Pro: la manutenzione è semplice. durante l'esportazione del report dalla pagina we, abbiamo osservato un miglioramento delle prestazioni rispetto ai report lato server.

se si desidera utilizzare il report in asp.net, utilizzare .rdl se si desidera utilizzare / visualizzare nel generatore di report / server di report, quindi utilizzare .rdlc semplicemente convertendo il formato manualmente funziona