Extract metadata por código

[[Ivanzinho]]

Hola foro, quería saber si conocen alguna forma de extraer el metadata de una base de datos firebird desde código Delphi, y posteriormente crear una nueva BD ejecutando este metadata. Utilizo Delphi 7 y Firebird 1.52. El caso es el siguiente :

Tengo una aplicación en la que se pueden declarar distintas empresas a gestionar, las cuales tendrán sus propias bases de datos indepentedientes. Lo que quiero es que el usuario administrador de la aplicación pueda crear nuevas empresas y por tanto sus correspondientes BD sin la mediación de un informático.

Había pensado, en caso de que no se posible la extracción del metadata, hacer el backup/restore de una BD existente y luego vaciarla por medio de un procedimiento almacenado, pero este tiene el problema que habria que actualizarlo cada vez que se agregen o borren tablas de la BD, a no ser, que se pueda recorrer alguna tabla de sistema en donde se encuentren las distintas tablas e irlas borrando.

En definitiva, ¿que me aconsejan?.

Gracias.

Un saúdo

[[ArdiIIa]]

Precisamente estos días estuve tocando este tema y te recomiendo la utilización de unos componentes que trae Marathon y que realiza ese cometido perfectamente. De hecho, Marathon incorpora una dll que mediante OLE es la encargada de gestionar eso, y de la cual está disponible todo el código.

Te pongo un archivo con el que estaba realizando pruebas, este en particular trataba de sacar la metadata y generar los DOMAINS de una DB que carecía de ellos.
Verás que ellos que se utilizan los componentes de Marathon ademas del VirtualTreeView.

Otra opción mas simple, es utilizar el IbExtract (de la paleta interbase), aunque es menos versátil que lo que te comentaba anteriormente.

ARCHIVO

Saludos

[[Ivanzinho]]

Muchas gracias por la respuesta Ardilla, voy a revisar lo que me pasaste y ya comentaré como me fué.

Un saúdo.

[[ArdiIIa]]

Empezado por Ivanzinho

Tengo una aplicación en la que se pueden declarar distintas empresas a gestionar, las cuales tendrán sus propias bases de datos indepentedientes. Lo que quiero es que el usuario administrador de la aplicación pueda crear nuevas empresas y por tanto sus correspondientes BD sin la mediación de un informático.

Leyendo esto mas detenidamente y considerando que el programa es "multi-empresa" ten en cuenta que no sería necesario que cada empresa contara con su propia BD (a no ser que sea requisito indispensable), si los datos son comunes a todas ellas, podrías estructurar la DB de tal forma que todas las tablas tengan en campo EMRPRESA y de este modo poder discernir de que empresa son los datos. De este modo a mi me parece algo más sólido que tener varias DB.

[[Ivanzinho]]

Empezado por ArdiIIa

Leyendo esto mas detenidamente y considerando que el programa es "multi-empresa" ten en cuenta que no sería necesario que cada empresa contara con su propia BD (a no ser que sea requisito indispensable), si los datos son comunes a todas ellas, podrías estructurar la DB de tal forma que todas las tablas tengan en campo EMRPRESA y de este modo poder discernir de que empresa son los datos. De este modo a mi me parece algo más sólido que tener varias DB.

Pensé en ello al iniciar la aplicación, pero al final me decidí por una BD por empresa por los siguentes motivos: BackUp independiente por empresa, BD más ligeras, si se fastidia un fichero .fdb solo tengo que restaurar los datos de esa empresa, a la hora de programar me parecio mas simple el tener separadas las empresas, ... Pero puedo estar equivocado, es solo mi opinión, ¿a qué te refieres con que sea más sólido?

Un saúdo.

[[ArdiIIa]]

Empezado por Ivanzinho

Pensé en ello al iniciar la aplicación, pero al final me decidí por una BD por empresa por los siguentes motivos: BackUp independiente por empresa, BD más ligeras, si se fastidia un fichero .fdb solo tengo que restaurar los datos de esa empresa, a la hora de programar me parecio mas simple el tener separadas las empresas, ... Pero puedo estar equivocado, es solo mi opinión, ¿a qué te refieres con que sea más sólido?
.

Precisamente a eso, a la hora de diseñar la DB y programar, puede resultar algo mas arduo, pero una vez montado resulta muy eficaz:

Código SQL [-]
 "Select * From Facturas where empresa = Empresa_seleccionada"

Por contra, del otro modo estás obligado al mantenimiento de tantos FDB como empresas tengas.
Claro está que todas las consideraciones que se puedan hacer al respecto pueden ser variadas, pero una de las ventajas que yo le veo a Firebird con respecto a otros sistemas es que no "desperdigan" varios ficheros por el disco, sino que todo lo hacen en un solo fichero y siguiendo esa política, es por lo que en mi humilde opinión, veo más sólido el tener un solo fichero, pero tal y como comento, esto no tiene porqué ser ley, siempre habrá que adaptarse a los requerimientos.

[[Ivanzinho]]

Lo del mantenimiento del los FDB fué una cosa en la que pensé al plantearme 1 BD por aplicación o 1 BD por empresa, pero como se trata de una aplicación que tratará a lo sumo 5 empresas me decidí por la segunda opción. Otra cosa sería una aplicación para una gestoría que puede tratar cientos de empresas, entonces podría planteame otra forma, pero en este caso me decidí por este método porque non le vi ninguna desventaja a tener una sola BD. Pero bueno, creo que esto ya se escapa del tema del hilo y en caso de ser necesario se debería continuar con la discusión en uno nuevo.

Muchas gracias de nuevo por tu interes.

Un saúdo

[[RONPABLO]]

Yo tengo una aplicacion que trabaja con 3 bds diferentes y no veo la hora de tener tiempo para ponerlas en una sola, perder el poder que dan los query y dejarle todo el enlace de empresas a Delphi no es bueno, es mejor que los querys te den los resultados discriminados, en algun momento vas a necesitar juntar datos de una empresa a otra y vas a tener que consultar en firebird la bd de una empresa, ir a Delphi para tener unos datos de la empresa, enviar los filtros otra vez a firebird en la otra bd, volver a consultar, volver a Delphi y al final para juntar la informacion. Cuando sean muchos datos esto se volvera muy lento y cada vez mas complejo.
un solo ejemplo como harias la siguiente consulta en varias bd:

Código SQL [-]
Select * from Empresas a where 
a.id not in (select b.empresa from InsumosEntreempresas b)

Recuerda que Firebird no permite querys entre bds