Copiando completamente o parcialmente una Base de Datos (1)

1 comentario

A veces puedes querer copiar una Base de Datos completa, con todo su contenido, pero a veces puede interesarte copiar solamente una parte de ella. Por lo tanto, tus opciones serían:

  1. Copiarla totalmente. Con todos sus metadatos y todos sus datos
  2. Copiar solamente los metadatos. Es decir, su estructura
  3. Copiar todos los metadatos y el contenido de algunas tablas
  4. Copiar algunos metadatos y el contenido de algunas tablas

Como el tema es largo, será tratado en 2 artículos. En este veremos como realizar esas tareas manualmente, o sea sin usar un programa de administración gráfica y en el siguiente artículo usaremos un programa de administración gráfica.

Opción 1. Copiarla totalmente. Con todos sus metadatos y todos sus datos

Para este caso lo más recomendable es hacer un backup usando el programa GBAK. ¿Por qué es lo más recomendable? porque al hacer un backup con GBAK se elimina la basura que contenía la Base de Datos original y en el backup no hay basura, ni índices (que serán creados cuando se restaure el backup), y el identificador de todas las transacciones del backup es puesto en cero.


GBAK -b MiBaseDatos.FDB MiBackup.FBK -user SYSDBA -password masterkey

Si el Servidor del Firebird no está funcionando también se puede copiar la Base de Datos con el Explorador de Windows o algún programa similar. ¿Por qué el Servidor del Firebird no debe estar funcionando? Porque si lo está y alguien está conectado, la Base de Datos puede corromperse. Y si nadie está conectado existe el riesgo (pequeño, pero existe) de que el Servidor esté realizando alguna tarea en la Base de Datos (por ejemplo, un sweep). Por lo tanto, copiar con el Explorador del Windows solamente es seguro si el Servidor del Firebird está apagado.

Opción 2. Copiar solamente los metadatos. Es decir, su estructura

El programa GBAK tiene la opción -m la cual copia solamente los metadatos. Su sintaxis es:


GBAK -b -m MiBaseDatos.FDB MiBackup.FBK -user SYSDBA -password masterkey

Opción 3. Copiar todos los metadatos y el contenido de algunas tablas

Para este caso lo mejor es crear un archivo de script con el contenido completo de la Base de Datos y luego eliminar lo que no nos interesa, modificar lo que queremos cambiar, y dejar como está a lo demás.

El programa ISQL tiene una opción -extract que sirve para crear un script de toda la Base de Datos.

COPIAR04

Captura 1. Si haces clic en la imagen la verás más grande

En la Captura 1. vemos que todo el contenido de la Base de Datos DEISY.FDB fue copiado al archivo de script llamado DEISY.SQL

COPIAR05

Captura 2. Si haces clic en la imagen la verás más grande

El archivo de script DEISY.SQL por supuesto que es muchísimo más largo, en la Captura 2. se muestran solamente las primeras líneas.

Ahora, tenemos la posibilidad de eliminar lo que ya no nos interesa tener y de modificar cualquier cosa. Podemos cambiar el nombre o el contenido de los dominios, de las tablas, de los stored procedures, etc. Lo que se nos ocurra.

Después de haber eliminado y modificado todo lo que quisimos, para generar una nueva Base de Datos, debemos quitarle el comentario a la línea CREATE DATABASE, poner el nombre que tendrá la nueva Base de Datos, y el usuario y la contraseña que la creará.

COPIAR06

Captura 3. Si haces clic en la imagen la verás más grande

Para crear la Base de Datos llamada DEISY2.FDB, ingresamos a ISQL y con el comando INPUT ejecutamos el script. Todo lo que esté escrito dentro del script será ejecutado.

COPIAR07

Captura 4. Si haces clic en la imagen la verás más grande

Si todo está bien, la nueva Base de Datos será creada. Si hay algún error, habrá que encontrar cual es el error y corregirlo. Luego, se vuelve a intentar crear la Base de Datos.

Copiando solamente el contenido de algunas tablas

Hasta ahora hemos visto como copiar a una Base de Datos completa, con todos sus metadatos y todos sus datos. Pero ¿y si queremos copiar solamente el contenido de algunas tablas?

Para eso entramos a ISQL, nos conectamos a una Base de Datos, y usando el comando OUTPUT enviamos a un archivo de texto todo lo que hacemos, tal y como vemos a continuación:

COPIAR01

Captura 5. Si haces clic en la imagen la verás más grande

La primera línea le indica al ISQL que todo lo que se escriba a continuación se guarde en un archivo de texto. No se verá en la pantalla, sino que se guardará en el archivo cuyo nombre se escriba después de la palabra OUTPUT.

Ese nombre puede ser cualquiera y puede tener cualquier extensión. Para los datos se acostumbra a ponerle la extensión .DAT pero eso no es obligatorio.

El OUTPUT que se encuentra en la tercera línea se usa para que la salida vuelva a verse en la pantalla, o sea que dejará de enviarse al archivo de texto.

Entre el primer OUTPUT y el segundo OUTPUT puede haber muchas líneas, no solamente una como en este ejemplo.

En el contenido del archivo de texto BANCOS.DAT se verá algo como:

COPIAR02

Captura 6. Si haces clic en la imagen la verás más grande

Donde, como puedes ver, se muestra el nombre de cada columna y el contenido de cada fila.

Opción 4. Copiar algunos metadatos y el contenido de algunas tablas

Es igual a la Opción 3.

Conclusión:

Como has podido ver en este artículo, con Firebird tenemos la posibilidad de realizar backups completos o parciales de nuestra Base de Datos.

Enviar el backup a un archivo de script tiene la gran ventaja de que todo es legible y así podríamos revisar ese script y descubrir errores o mejoras que se podrían realizar.

Artículos relacionados:

Entendiendo a los scripts

Usando scripts para documentar la Base de Datos

Ejecutando un script desde Visual FoxPro

El índice del blog Firebird21

El foro del blog Firebird21

Anuncios

Usando Database Comparer en línea de comandos

4 comentarios

En el artículo:

https://firebird21.wordpress.com/2013/06/10/database-comparer-de-clever-components/

ya habíamos hablado sobre un programa muy bueno para comparar bases de datos llamado Database Comparer, de la empresa Clever Components.

Pues bien, ese programa además de permitirnos interactuar con él por medio del GUI (Graphical User Interface) también nos permite ejecutarlo a través de la línea de comandos, como veremos ahora.

¿Y para qué nos serviría ejecutarlo a través de la línea de comandos?

La utilidad más normal de esta característica es que podemos automatizar el proceso en nuestra aplicación (o sea, en el archivo .EXE que nosotros creamos y que los usuarios ejecutan).

En nuestro .EXE podemos hacer que la comparación (y actualización, si es necesaria) se haga en forma automática o cuando el usuario haga clic sobre algún botón.

Veamos la situación:

Estamos desarrollando un sistema de contabilidad que será usado por muchos estudios contables. Un estudio contable normalmente lleva la contabilidad de muchos clientes. Como sabemos que no es bueno tener en una sola Base de Datos a todos los clientes del estudio contable sino que lo recomendable es que cada uno de sus clientes tenga su propia Base de Datos nos encontramos con un problema.

¿Cuál es el problema?

Que la estructura de una Base de Datos (es decir, sus metadatos) no es fija, por mucho que la hayamos analizado siempre cabe la posibilidad de que alguna vez debamos crear una tabla, o modificar una existente, agregarle índices, vistas, stored procedures, triggers, etc.

Si el estudio contable solamente tuviera uno o dos clientes sería muy sencillo. Con la GUI de Database Comparer en un ratito actualizaríamos las bases de datos y listo, a otra cosa.

Pero lo normal es que los estudios contables tengan decenas o centenas de clientes, y allí la actualización manual ya se vuelve muy impráctica, demora mucho tiempo, y existe la gran posibilidad de no actualizar todas las bases de datos o hacerlo de manera equivocada (actualizando al revés), con la consecuencia de que podrían perderse muchos datos y todos los trastornos que eso ocasionaría.

El comportamiento adecuado

Ante una situación como la antedicha, ¿qué es lo mejor?

  1. Creamos una Base de Datos vacía, modelo, que solamente tiene los metadatos. Por ejemplo la llamamos MASTER.FDB
  2. Por cada cliente del estudio contable tenemos una Base de Datos que cuando se agregó ese cliente simplemente se copió físicamente a MASTER.FDB para tener la Base de Datos del cliente. Así podríamos tener ALICIA.FDBGRACIELA.FDB, SUSANA.FDB, etc., las cuales inicialmente eran una simple copia de MASTER.FDB y después se les fueron agregando los datos que les correspondían.
  3. Cuando debemos cambiar algo en la Base de Datos, la única Base de Datos que tocamos, la única con la cual trabajamos es MASTER.FDB
  4. Cuando el usuario abre una Base de Datos, nuestro programa .EXE compara la versión de MASTER.FDB con la versión de la Base de Datos que él abrió. Por ejemplo, si abrió GRACIELA.FDB se compara a MASTER.FDB con GRACIELA.FDB
  5. Para comparar a ambas bases de datos lo mejor es que tengan una tabla, por ejemplo llamada VERSION con una columna llamada por ejemplo VER_NUMERO. Si el número de versión de MASTER.FDB es más nuevo que el número de versión de GRACIELA.FDB entonces estamos seguros de que GRACIELA.FDB debe ser actualizada
  6. Si descubrimos que GRACIELA.FDB debe ser actualizada, entonces nuestro programa .EXE ejecuta a Database Comparer con sus parámetros de la línea de comandos
  7. De esta manera, no importa si el estudio contable tiene cientos de bases de datos, cada vez que el usuario abra una de esas bases de datos se la comparará con MASTER.FDB y en el caso de que la versión de MASTER.FDB sea más nueva entonces se actualizará la Base de Datos que el usuario abrió.
  8. Y estaremos seguros de que sea cual sea la Base de Datos que el usuario abra, y aunque hayan pasado meses o años desde la última vez que la abrió, siempre estará correctamente actualizada.
  9. Lo único que debemos recordar es que cada vez que cambiamos algo en MASTER.FDB debemos actualizar la columna VER_NUMERO de la tabla VERSION, escribiendo un número que sea mayor que el que existía ahí.

La interfaz de línea de comandos de Database Comparer

Si abrimos una ventanita “Símbolo del sistema”, nos ubicamos en una carpeta donde se encuentre el programa DBCOMPARER.EXE y lo ejecutamos con la opción /? veremos las opciones disponibles.

DBCOMPARER

Captura 1. Si haces clic en la imagen la verás más grande

Ejemplo de uso

Al programa DBCOMPARER.EXE podemos copiarlo en cualquier carpeta, no es necesario ni obligatorio ejecutarlo en la carpeta donde fue instalado. Lo mejor generalmente es copiar a DBCOMPARER.EXE y al archivo IBDB_CMP.CFG (donde se guardan los alias, las ubicaciones de las bases de datos, etc.) a la misma carpeta donde se encuentra nuestro programa .EXE

DBCOMPARER2

Captura 2. Si haces clic en la imagen la verás más grande

Al escribir el comando anterior lo que hacemos es decirle a DBCOMPARER que compare a la Base de Datos cuyo alias en ese programa es MASTER con la Base de Datos cuyo alias en ese programa es PRUEBA1. Si hay diferencias entonces PRUEBA1 cambiará para que sus metadatos sean idénticos a los metadatos de MASTER.

Cuando el programa finalice, estaremos seguros de que ambas bases de datos tienen exactamente la misma estructura.

Conclusión:

Database Comparer es una muy buena aplicación para comparar las estructuras de las bases de datos y para hacer que sean idénticas en caso de que tengan diferencias.

Si las bases de datos a comparar son pocas, el proceso puede ser realizado manualmente, es muy sencillo, nada complicado.

Pero si las bases de datos son muchas, entonces hacerlo manualmente demorará mucho tiempo y además se corre el riesgo de no compararlas a todas o de compararlas en el sentido erróneo. Por lo tanto es mucho mejor automatizar ese proceso.

La interfaz de línea de comandos justamente nos permite automatizar la comparación y actualización. Por eso, es conveniente usarla.

Enlaces:

http://www.clevercomponents.com/products/dbcomparer/index.asp

http://www.clevercomponents.com/products/index.asp

http://www.clevercomponents.com/downloads/index.asp

Artículos relacionados:

Database Comparer de Clever Components

El índice del blog Firebird21

El foro del blog Firebird21

¿Cuándo se actualiza la estructura de una tabla?

4 comentarios

Si con un programa cambias la estructura de una tabla y con otro programa quieres usar esos cambios notarás que a veces no puedes hacerlo.

Veamos un ejemplo:

El usuario ejecuta su programa de Contabilidad y está trabajando con ese programa. Quiere introducir el nombre de un Proveedor y la columna le queda corta, digamos que solamente puede introducir 25 caracteres y él necesita introducir 31. Te llama y tú le dices: “ok, no hay problema, ya te actualizo la estructura de la tabla”.

Entonces vas, abres el EMS SQL Manager (o cual sea tu administrador gráfico), y cambias el ancho de la columna a 40, compilas la tabla, y está todo ok. Haces una prueba modificando esa columna en una fila cualquiera para que tenga 40 caracteres, le haces el COMMIT correspondiente y todo bien, funcionó perfecto. Desde luego, para terminar tu prueba borras los caracteres que le habías agregado a esa columna para probar, para que no queden registrados.

Ya has comprobado que aumentar el tamaño de la columna funcionó perfectamente entonces le llamas al usuario, y le dices: “ya está, ya podrás introducir hasta 40 caracteres en esa columna”.

El usuario feliz intenta nuevamente grabar los 31 caracteres que necesitaba grabar y … ¡¡¡NO FUNCIONA!!!

Te llama y te dice: “sigue sin funcionar, está igual que antes”

Entonces tú como eres muy educado a él no le dices una palabra pero dentro tuyo piensas: “¡¡¡la regranp…que lo recontraparió!!! ¡¡¡CÓMO QUE NO FUNCIONA!!! ¡¡¡Acabo de probar y funcionaba perfecto!!!”

Vuelves a probar y funciona bien. El usuario vuelve a probar y no le funciona.

¿Qué está pasando, cuál es el problema?

Que en tu programa los cambios sí funcionan, pero en el programa del usuario no. ¿Por qué?

Porque tú mantienes abierta a la Base de Datos en tu EMS SQL Manager (o cual sea tu administrador gráfico) y por lo tanto el usuario no se enterará de los cambios que hiciste hasta que no cierres la Base de Datos o salgas de ese programa.

Y en ocasiones, puede requerirse que el usuario también salga de su programa y vuelva a entrar.

Conclusión:

Que tú hagas un cambio a la estructura de una tabla no significa que al instante todos los usuarios se enteran de ese cambio, no es así. Para que se enteren debes salir del programa que usaste para realizar los cambios (el EMS SLQ Manager, el IBEXPERT, el FlameRobin, etc.) y en ocasiones el usuario también deberá salir del programa que él estaba usando. Solamente después de eso los cambios a la estructura de la tabla serán visibles.

Así que si haces cambios a una tabla y el usuario no ve esos cambios, no te desesperes. Simplemente sal de tu administrador gráfico y pídele al usuario que también salga del programa que estaba usando; cuando vuelva a entrar el asunto estará solucionado.

Artículo relacionado:

El índice del blog Firebird21