¿Está almacenando Crystal Reports Files en la base de datos?

Question

Tengo una interfaz de usuario que habla y manipula una base de datos de SQL Server, y una de las cosas que puede hacer es ejecutar informes sobre los datos en la base de datos.

Esta interfaz de usuario se puede instalar en varias computadoras, y hasta ahora solo he mantenido los informes en una carpeta con la instalación, pero esto significa que cada vez que se agrega un nuevo informe se debe copiar manualmente a cada única interfaz de usuario instalar allí.

Estaba pensando en almacenar los archivos .rpt en la base de datos (As Blobs) y tener algún mecanismo para que la interfaz de usuario los busque cuando sea necesario como forma de centralizar los informes y eliminar este problema.

¿Alguien ha intentado esto, y funcionó bien? O si no lo has hecho, ¿puedes pensar en algo que deba tener en cuenta antes de seguir adelante con esto? ¿Alguna sugerencia, trucos o advertencias que puedas pensar que puedan ser útiles para mí?

Answer 1

¡Gran pregunta! Es una especie de coincidencia ya que en realidad lo hemos implementado en los últimos seis meses.

Como ha sugerido, almacenamos el archivo rpt dentro de la base de datos, pero hacemos esto en Server 2005 como un tipo de imagen. Funciona muy bien y, en lo que respecta a la base de datos, realmente no hay advertencias que se te ocurran.

Obviamente, la forma en que accede a esta información cambia con la API. Si está utilizando C#, esto se traduce en el uso de BinaryReader para cargar en el archivo rpt, tomando un array de bytes. Esta matriz de bytes continuación, se puede pasar a la base de datos, a través de un procedimiento almacenado, etc.

Soy consciente de que usted está pidiendo específicamente sobre manchas y Server 2008, pero esto funciona tanto en Server 2005 y Server 2008 . Espero que esto arroje un poco de luz.

¡Si necesita detalles más específicos, me gustaría compartirlos!

Answer 2

Aquí hay un gran podcast con Paul Randal (escribió partes de DBCC!) Donde hablan sobre la nueva característica filestream en sql server 2008 para manejar blobs, pero también entran en el tamaño de archivos que funcionan y no funcionan así como blobs como parte de la charla. Creo que te ayudaría http://www.runasradio.com/default.aspx?showNum=74

Acabo de descubrir que el documento de FILESTREAM de 25 páginas que escribió Paul ha sido publicado en MSDN. http://msdn.microsoft.com/en-us/library/cc949109.aspx.

Según la investigación citada más adelante en este documento, BLOBs más pequeños que 256 kilobytes (KB) (como iconos de artilugios) se almacenan mejor dentro de una base de datos, y BLOBs más grandes que 1 megabyte (MB) se almacenan mejor la base de datos. Para aquellos con un tamaño de entre 256 KB y 1 MB, la solución de almacenamiento más eficiente depende de la relación lectura/escritura de los datos y de la tasa de "sobrescritura". El almacenamiento de datos BLOB únicamente dentro de la base de datos (p. Ej., Utilizando el tipo de datos varbinary (max)) está limitado a 2 gigabytes (GB) por BLOB.

Answer 3

Bien, ahora todos podemos almacenar fácilmente un BLOB en un servidor SQL, ORACLE, SQLITE, servidor MYSQL y cualquier otra base de datos que valga la pena. Lo que me pregunto es después de que obtuviste la matriz de bytes del DB, ¿cómo creaste el informe?

Quiero hacer lo mismo, pero lo único que se me ocurre es extraer el archivo del DB, crear un archivo físico en una carpeta Temp y luego usar la dirección física del nuevo archivo para crear el Informe de cristal. ¿Hay alguna forma de crear un Informe de Crystal desde una secuencia de memoria o una matriz de bytes? .

Answer 4

archivo .RPT podría ser almacenada en la base de datos (SQL) al tener que tipo de matriz de bytes como image.Store en base de datos y luego recuperarlo en forma de corriente (PISTA: tratarlo como archivo de imagen.)