Pergunta

Eu tenho um front end da interface do usuário que fala e manipula um banco de dados do SQL Server, e uma das coisas que ele pode fazer é executar relatórios nos dados no banco de dados.

Esta interface do usuário pode ser instalada em vários computadores e, até agora, eu tenho mantido os relatórios em uma pasta com a instalação, mas isso significa que sempre que um novo relatório é adicionado, deve ser copiado manualmente para cada instalação da interface do usuário lá.

Eu estava pensando em armazenar os arquivos .rpt no banco de dados (como blobs) e ter algum mecanismo para a interface do usuário buscá -los quando necessário como uma maneira de centralizar os relatórios e eliminar esse problema.

Alguém já tentou isso e funcionou bem? Ou, se não o fizer, você pode pensar em algo que devo levar em consideração antes de seguir em frente com isso? As dicas, truques ou advertências que você pode pensar que podem ser úteis para mim?

Foi útil?

Solução

Ótima pergunta! É meio que coincidência, pois na verdade acabamos de implementar isso nos últimos seis meses.

Como você sugeriu, armazenamos o arquivo RPT no banco de dados, mas fazemos isso no Server 2005 como um tipo de imagem. Funciona muito bem e, no que diz respeito ao banco de dados, realmente não há advertências que vêm à mente.

Obviamente, a maneira como você acessa essas informações muda com a API. Se você está usando C#, isso se traduz em usar um BinaryReader para carregar no arquivo RPT, pegando um Array de bytes. este Array de bytes pode então ser passado para o banco de dados, através de um procedimento armazenado, etc.

Percebo que você está perguntando especificamente sobre blobs e servidor 2008, mas Isso funciona no servidor 2005 e no servidor 2008. Espero que isso lança um pouco de luz.

Se você precisar de detalhes mais específicos, ficaria feliz em compartilhar!

Outras dicas

Aqui está um ótimo podcast com Paul Randal (ele escreveu partes do DBCC!), Onde eles falam sobre o novo recurso Filestream no SQL Server 2008 para lidar com blobs, mas também entram no tamanho dos arquivos que fazem e não funcionam bem como blobs como parte da conversa. Eu acho que isso ajudaria você.http://www.runasradio.com/default.aspx?shownum=74

Acabei de descobrir que o whitepaper Filestream Paper, de 25 páginas, que Paul escreveu foi publicado no MSDN.http://msdn.microsoft.com/en-us/library/cc949109.aspx.

Com base na pesquisa citada posteriormente neste papel branco, os blobs menores que 256 kilobytes (KB) (como ícones de widgets) são melhor armazenados dentro de um banco de dados e os blobs maiores que 1 megabyte (MB) são melhor armazenados fora do banco de dados. Para aqueles que dimensionam entre 256 kb e 1 MB, a solução de armazenamento mais eficiente depende da taxa de leitura versus gravação dos dados e da taxa de "substituição". O armazenamento de dados do blob exclusivamente no banco de dados (por exemplo, usando o tipo de dados varbinário (max) é limitado a 2 gigabytes (GB) por blob.

Ok, então todos nós agora podemos armazenar facilmente um blob em um servidor SQL, Oracle, SQLite, MySQL Server e qualquer outro banco de dados que valha a pena. O que estou pensando é que você pegou a matriz de bytes do banco de dados como você criou o relatório?

Estou querendo fazer a mesma coisa, mas a única coisa que consigo pensar é puxar o arquivo do banco de dados, criando um arquivo físico em uma pasta temporária e usando o endereço físico do novo arquivo para criar o relatório de cristal. Existe alguma maneira de criar um relatório de cristal a partir de um fluxo de memória ou matriz de bytes?

O arquivo .rpt pode ser armazenado no banco de dados (SQL), digitando -o como Image.store Byte Array no banco de dados e depois recupere -o como fluxo. (Dica: trate -o como arquivo de imagem.)

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top