Tenho estudado o SSRS 2005/2008 nas últimas semanas e criei alguns relatórios do lado do servidor. Para alguma aplicação, um colega sugeriu que eu procurasse RDLC para essa situação particular. Agora estou tentando entender a principal diferença entre RDL e RDLC.

A busca por essas informações rende, na melhor das hipóteses, informações fragmentadas. Eu aprendi que:

• Os relatórios RDLC não armazenam informações sobre como obter dados.
• Os relatórios RDLC podem ser executados diretamente pelo controle ReportViewer.

Mas ainda não entendo totalmente a relação entre o arquivo RDLC e os outros sistemas relacionados (o Reporting Server, o banco de dados de origem, o cliente).

Para ter uma boa compreensão dos arquivos RDLC, gostaria de saber como seu uso difere dos arquivos RDL e em que situação se escolheria RDLC em vez de RDL. Links para recursos também são bem-vindos.

Atualizar:

Um tópico nos fóruns ASP.NET discute esse mesmo problema. A partir daí, obtive um melhor entendimento sobre o assunto.

Um recurso do RDLC é que ele pode ser executado completamente do lado do cliente no controle ReportViewer.

• Isso remove a necessidade de uma instância do Reporting Services e até remove a necessidade de qualquer conexão de banco de dados, mas:
• Ele adiciona o requisito de que os dados necessários no relatório sejam fornecidos manualmente.

Se isso é uma vantagem ou uma desvantagem, depende da aplicação específica.

Em meu aplicativo, uma instância do Reporting Services está disponível de qualquer maneira e os dados necessários para os relatórios podem ser facilmente obtidos de um banco de dados. Resta alguma razão para eu considerar o RDLC ou devo simplesmente ficar com o RDL?

Pela minha experiência, há poucas coisas em que pensar sobre as duas coisas:

I. Relatórios RDL geralmente são relatórios HOSTED. Isso significa que você precisa implementar o Servidor SSRS. Eles são uma extensão integrada do Visual Studio do SQL Server para a linguagem de relatórios. Ao instalar o SSRS, você deve ter um complemento chamado 'Business Intelligence Development Studio', que é muito mais fácil de trabalhar com os relatórios do que sem ele.

R elatório

D EFINIÇÃO

L angauge

Benefícios dos relatórios RDL:

1. Você pode hospedar os relatórios em um ambiente que tenha serviços em execução para você.
2. Você pode configurar a segurança em um item ou nível de herança para lidar com a segurança como um conceito autônomo
3. Você pode configurar o serviço para enviar e-mails (desde que tenha um servidor SMTP ao qual tenha acesso) e salvar arquivos em programações
4. Você tem um banco de dados geralmente chamado de 'ReportServer' e pode consultar informações sobre os relatórios publicados.
5. Você pode acessar esses relatórios ainda por meio de 'ReportViewer' em um aplicativo cliente escrito em ASP.NET, WPF (com um controle winform bleh!) Ou Winforms em .NET usando 'ProcessingMode.Remote'.
6. Você pode definir parâmetros que um usuário pode ver e usar para obter mais flexibilidade.
7. Você pode configurar partes de um relatório para serem usadas em strings de conexão como 'Fontes de dados', bem como uma consulta sql, xml ou outros conjuntos de dados como um 'Conjunto de dados'. Essas partes e outras podem ser armazenadas e configuradas para armazenar dados em cache regularmente.
8. Você pode escrever classes de proxy .NET dos serviços http: // / ReportServer / ReportingService2010 ou / ReportExecution2005. Você pode então criar seus próprios métodos em .NET para enviar por e-mail, salvar ou manipular dados SSRS do serviço diretamente de um servidor que hospeda relatórios SSRS em código. Exportar relatório SSRS programaticamente do sharepoint usando ReportService2010.asmx

Desvantagens:

1. O SSRS é meio complicado em comparação com outras coisas sobre como fazê-lo funcionar rapidamente. A maioria das pessoas fica confusa com a política de segurança e a criação de relatórios como um 'complemento' do VS. SQL 2005 = VS BIDS 2005, SQL 2008 = VS BIDS 2008, SQL 2012 = VS BIDS 2010 (LOL).
2. Continuando em 1, a política de configurações de segurança IMHO são idiotamente complicadas. Há segurança do servidor, segurança do banco de dados e funções, duas configurações de segurança na página hospedada para o serviço. A maioria das pessoas apenas configura um administrador do que não consegue entrar e se pergunta por que outros usuários não conseguem. A reclamação ou pergunta mais comum sobre o SSRS está relacionada à minha experiência em geral.
3. Você pode usar 'expressões' que supostamente 'melhorarão' o seu relatório. Freqüentemente, você faz mais do que algumas vezes e seu relatório apresenta um rastreamento de desempenho.
4. Você tem uma quantidade definida de coisas que pode fazer e exportar. O SSRS não passa sobre relatórios que eu conheço sem um hack de javascript.
5. A velocidade e o desempenho podem ser prejudicados, pois a configuração idiota do SSRS recicla o sistema e um primeiro relatório pode demorar um pouco, às vezes, apenas carregando o site. Você pode contornar isso alterando-o, mas descobri que fazer um serviço keep alive para ele funciona melhor.

II. Os relatórios RDLC são relatórios CONTIDOS pelo CLIENTE que NÃO SÃO HOSPEDADOS EM QUALQUER LUGAR. O c extra no nome significa 'Cliente'. Geralmente, esta é uma extensão da linguagem RDL destinada ao uso apenas em aplicativos cliente do Visual Studio. Ele existe no Visual Studio quando você adiciona um item de 'relatório'.

Benefícios dos relatórios RDLC:

1. Você pode conectar um serviço wcf de forma muito mais fácil ao conjunto de dados.
2. Você tem mais controle sobre o conjunto de dados e pode usar classes POCO preenchidas com objetos da estrutura Entity ou ADO.NET diretamente, bem como as próprias tabelas. Você pode manipular os dados para otimizá-los antes de vinculá-los ao relatório.
3. Você pode personalizar a aparência com add-ons diretamente no code-behind.

Desvantagens:

1. Você precisa lidar com os parâmetros por conta própria e, embora possa implementar métodos de invólucro para ajudar o trabalho braçal, é um pouco mais do que o esperado e infeliz.
2. O usuário não pode VER os parâmetros em um controle 'ReportViewer' a menos que esteja no modo remoto e acessando um relatório RLD. Portanto, você precisa criar caixas de texto, menus suspensos e botões de opção por conta própria, fora do controle, para passar para ele. Algumas pessoas gostam deste controle adicional, eu não pessoalmente.
3. Qualquer coisa que você queira fazer com a manutenção dos relatórios para distribuição, você precisa construir você mesmo. Enviando por e-mail, assinaturas, salvando. Desculpe, você precisa construir isso no .NET ou então implementar um proxy que já faz isso de cima para baixo, você pode apenas obter relatórios hospedados.

Honestamente, gosto de ambos para finalidades diferentes. Se eu quiser que algo saia para os analistas que eles usam o tempo todo e ajustam gráficos, tabelas, detalhamentos e exportações para o Excel, eu uso RDL e apenas peço ao site do SSRS para fazer todo o trabalho braçal de lidar com as distribuições de e-mail. Se eu quero um aplicativo que tem uma seção de relatório e sei que o aplicativo é seu próprio módulo com regras e governança, uso um RDLC e tendo os parâmetros menores e orientados pelas decisões que o usuário fez antes de chegar à parte do relatório cliente eles estão no site e, em seguida, geralmente escolhem um período de tempo ou tipo e nada mais. Então, geralmente um relatório complexo eu usaria RDL e para algo simples eu usaria RDLC IMHO.

Espero que ajude.

P: Qual é a diferença entre os formatos RDL e RDLC?

R: Os arquivos RDL são criados pela versão SQL Server 2005 do Report Designer. Os arquivos RDLC são criados pela versão Visual Studio 2008 do Report Designer.

Os formatos RDL e RDLC têm o mesmo esquema XML. No entanto, em arquivos RDLC, alguns valores (como texto de consulta) podem ficar vazios, o que significa que não estão imediatamente prontos para serem publicados em um Report Server. Os valores ausentes podem ser inseridos abrindo o arquivo RDLC usando a versão SQL Server 2005 do Report Designer. (Você deve renomear .rdlc para .rdl primeiro.)

Os arquivos RDL são totalmente compatíveis com o tempo de execução do controle ReportViewer. No entanto, os arquivos RDL não contêm algumas informações das quais depende o tempo de design do controle ReportViewer para gerar automaticamente o código de vinculação de dados. Vinculando dados manualmente, os arquivos RDL podem ser usados ​​no controle ReportViewer. Novo! Consulte também o programa de amostra RDL Viewer.

Observe que o controle ReportViewer não contém nenhuma lógica para conexão com bancos de dados ou execução de consultas. Ao separar essa lógica, o ReportViewer se tornou compatível com todas as fontes de dados, incluindo fontes de dados que não são de banco de dados. No entanto, isso significa que quando um arquivo RDL é usado pelo controle ReportViewer, as informações relacionadas ao SQL no arquivo RDL são simplesmente ignoradas pelo controle. É responsabilidade do aplicativo host conectar-se aos bancos de dados, executar consultas e fornecer dados para o controle ReportViewer na forma de ADO.NET DataTables.

http://www.gotreportviewer.com/

Sempre pensei que a diferença entre RDL e RDLC é que RDL são usados ​​para SQL Server Reporting Services e RDLC são usados ​​no Visual Studio para relatórios do lado do cliente. A implementação e o editor são quase idênticos. RDL significa Report Defintion Languagee RDLC Report Definition Language Client-side .

Espero que ajude.

Pela minha experiência, se você precisa de alto desempenho (isso depende um pouco das especificações do cliente) em relatórios grandes, use o rdlc. Além disso, os relatórios rdlc oferecem uma gama muito completa de controle sobre seus dados, você pode ser capaz de evitar o desperdício de viagens de banco de dados, etc., usando relatórios do lado do cliente. No projeto em que estou trabalhando atualmente, um relatório crítico requer cerca de 2 minutos para ser renderizado no lado do servidor e praticamente remove qualquer servidor de relatório que atingir naquele momento. Alternando para renderização do lado do cliente, vemos o desempenho muito mais próximo de 20-40 segundos sem carga no servidor de relatório e menos largura de banda usada porque apenas os conjuntos de dados estão sendo baixados.

Sua milhagem pode variar e eu acho que o rdlc adiciona complexidade de desenvolvimento e manutenção, especialmente quando seu relatório foi projetado como um relatório do lado do servidor.

Alguns desses pontos foram abordados acima, mas aqui estão meus 2 centavos para o ambiente VS2008.

RDL (relatórios remotos): Experiência de desenvolvimento muito melhor, mais flexibilidade se você precisar usar alguns recursos avançados como agendamento, relatórios ad-hoc, etc ...

RDLC (Relatórios locais): Melhor controle sobre os dados antes de enviá-los ao relatório (mais fácil de validar ou manipular os dados antes de enviá-los ao relatório). Implantação muito mais fácil, sem necessidade de uma instância do Reporting Services.

Uma GRANDE advertência com relatórios locais é um vazamento de memória conhecido que pode afetar gravemente o desempenho se seus clientes executarem vários relatórios grandes. Isso deve ser resolvido com a nova versão VS2010 do visualizador de relatórios.

No meu caso, como temos uma instância do Reporting Services disponível, desenvolvo novos relatórios como RDLs e depois os converto em relatórios locais (o que é fácil) e os implanto como relatórios locais.

Se você tiver uma infraestrutura de serviços de relatório disponível, use-a. Você achará o desenvolvimento de RDL um pouco mais agradável. Você pode visualizar o relatório, configurar parâmetros facilmente, etc.

Embora atualmente eu me incline para o RDL porque parece mais flexível e fácil de gerenciar, o RDLC tem a vantagem de simplificar o seu licenciamento. Como o RDLC não precisa de uma instância do Reporting Services, você não precisará de uma Licença do Reporting Services para usá-lo.

Não tenho certeza se isso ainda se aplica às versões mais recentes do SQL Server, mas ao mesmo tempo, se você optou por colocar as instâncias do banco de dados do SQL Server e do Reporting Services em duas máquinas separadas, era necessário ter duas licenças separadas do SQL Server:
http://social.msdn.microsoft.com/forums/en-US/sqlgetstarted/thread/82dd5acd-9427-4f64-aea6-511f09aac406/

Você pode usar o Bing para outros blogs e postagens semelhantes sobre o licenciamento do Reporting Services.

Para VS2008, acredito que RDL oferece melhores recursos de edição do que RDLC. Por exemplo, posso alterar o negrito em uma quantidade selecionada de texto em uma caixa de texto com RDL, enquanto em RDLC isso não é possível.

RDL: abcd efgh ijklmnop

RDLC: abcd efgh ijklmnop -ou- abcd efgh ijklmnop (são suas únicas opções)

Isso ocorre porque o RDLC está usando um namespace / formatação anterior de 2005, enquanto o RDL está usando 2008. No entanto, isso mudará com o VS2010

Se tivermos menos número de relatórios que são menos complexos e consumidos por páginas da web do asp.net. É melhor usar o rdlc, porque podemos evitar a manutenção de relatórios na instância do RS. mas temos que buscar os dados do banco de dados manualmente e vinculá-los ao rdlc.

Contras: projetar rdlc no visual studio é um pouco difícil em comparação com o designer SSrs.

Pro: a manutenção é fácil. ao exportar o relatório da página nós, observou que o ganho de desempenho em comparação com os relatórios do lado do servidor.

se você quiser usar o relatório em asp.net, use .rdl se quiser usar / visualizar no construtor de relatório / servidor de relatório, então use .rdlc apenas convertendo o formato manualmente, ele funciona