Actualización de bases de datos remotas.

[afxe]

Hola gente.

¿Cómo suelen actualizar las bases de datos de sus clientes?

En las aplicaciones en las que uso Firebird, tengo una pequeña aplicación que se conecta vía FTP a un servidor y trae o actualiza archivos que hayan cambiado con respecto a los ficheros locales del cliente, estos pueden ser EXE, DLL o script de bases de datos. Mis clientes ejecutan periodicamente este pequeño programa para comprobar si han habido actualizaciones en el software.

Lo primero que hace el software principal al arrancar es comprobar si existe algún script de SQL (nombrado de una manera especial) y si lo encuentra lo ejecuta (componente ibSQLScript). En dicho script van las modificaciones necesarias a la estructura de la base de datos (nuevos campos, modificaciones de triggers o stock procedures, etc...).

Esporádicamente esta técnica me ha dado algún que otro problema, pero en general funciona.

¿Qué otros métodos usais?

[Sick boy]

Yo aun no uso ningún metodo en concreto, pero pensaba utilizar algo muy similar a lo que has expuesto.

Pero me queda la duda, ya que dices que esporadicamente has tenido problemas, ¿qué problemas has tenido?

saludos

[afxe]

Hola Sick.

El método que sigo es el siguiente: Como comenté, creo archivos con instrucciones DDL (definición de datos), como adicción de campos y stock procedures o modificación de triggers, asignación de valores por defecto, etc... Dichos archivos están en un servidor FTP y los nombro VERnnnn.DDL, donde nnnn es un nº secuencial para mantener el orden de script. Cuando se ejecuta uno de estos scripts, almaceno en una tabla de la base de datos el nombre del script, la fecha y hora de ejecución. Si restauro una base de datos lo primero que se comprueba es esta tabla y si hay que pasar algún Script de actualización a la BD recien restauradas. Problemas que he tenido:

- Creación de Foreing Keys, la mayoría de las veces se necesita que las tablas estén cerradas, si alguien tiene abierta la base de datos no se crea la referencia de integridad y yo ni me entero...

- Si un usuario pasa mucho tiempo sin actualizarse la ejecución consecutiva de muchos scripts sin realizar un backup y un restore da problemas si hay cambios en la misma tabla o trigger... algo que tiene que ver con el sistema de transacciones del IB, hay hilos por ahí al respecto...

- Es muy importante el orden de ejecución de los scripts: me ha sucedido que a la hora de descargar del servidor FTP más de 3 o 4 scripts, alguno no se ha bajado correctamente y se han ejecutado el Script VER0034.DDL sin que se hubiera ejecutado el VER0033.DDL....

- Ejecución de instrucciones muy pesadas: Algún Update sobre ficheros de movimientos o estadisticos que han tardado mucho y el usuario apaga el equipo o aborta el programa pensando que está bloqueado, provocando que no se ejecuten todas las instrucciones.

Ya te digo que esto puede suceder en una de cada 40 actualizaciones, pero si tienes 50 clientes actualizándose una vez a la semana es normal que en un mes tengas 3 o 4 incidencias por errores de actualización (dependiendo del tipo de actualización que hagas).

Saludos.

[afxe]

La primera idea que tuve para actualizar las bases de datos de mis clientes era usar un sistema parecido al "Database Comparer" de CleverComponents o el IBComparer. Pensaba enviar el metadata de la base de datos maestra y que un programa en los clientes se autochequee contra esta BD maestra. Así no tengo que estar apuntando las modificaciones que hago en la base de datos para crear luego scripts y que los clientes no tengan que soportar el pasar varios scripts consecutivos.... Sin embargo no encontré ejemplos ni componentes que me hicieran esta tediosa acción y además, pasando el metadata hay cosas que no se pueden hacer, como por ejemplo, que tras la creación de un campo se inicialize a cero o que tras la modificación de un trigger se vuelva a pasar el recálculo de estadísticas... ¿me explico? Por eso quería saber que métodos de actualización están rulando.

[afxe]

Hola Sick.

El método que sigo es el siguiente: Como comenté, creo archivos con instrucciones DDL (definición de datos), como adicción de campos y stock procedures o modificación de triggers, asignación de valores por defecto, etc... Dichos archivos están en un servidor FTP y los nombro VERnnnn.DDL, donde nnnn es un nº secuencial para mantener el orden de script. Cuando se ejecuta uno de estos scripts, almaceno en una tabla de la base de datos el nombre del script, la fecha y hora de ejecución. Si restauro una base de datos lo primero que se comprueba es esta tabla y si hay que pasar algún Script de actualización a la BD recien restauradas. Problemas que he tenido:

- Creación de Foreing Keys, la mayoría de las veces se necesita que las tablas estén cerradas, si alguien tiene abierta la base de datos no se crea la referencia de integridad y yo ni me entero...

- Si un usuario pasa mucho tiempo sin actualizarse la ejecución consecutiva de muchos scripts sin realizar un backup y un restore da problemas si hay cambios en la misma tabla o trigger... algo que tiene que ver con el sistema de transacciones del IB, hay hilos por ahí al respecto...

- Es muy importante el orden de ejecución de los scripts: me ha sucedido que a la hora de descargar del servidor FTP más de 3 o 4 scripts, alguno no se ha bajado correctamente y se han ejecutado el Script VER0034.DDL sin que se hubiera ejecutado el VER0033.DDL....

- Ejecución de instrucciones muy pesadas: Algún Update sobre ficheros de movimientos o estadisticos que han tardado mucho y el usuario apaga el equipo o aborta el programa pensando que está bloqueado, provocando que no se ejecuten todas las instrucciones.

Ya te digo que esto puede suceder en una de cada 40 actualizaciones, pero si tienes 50 clientes actualizándose una vez a la semana es normal que en un mes tengas 3 o 4 incidencias por errores de actualización (dependiendo del tipo de actualización que hagas).

Saludos.

[Sick boy]

Me imaginaba que los errores podrían ser los que comentas.

Lo que voy a hacer es enviar al cliente una base datos vacia, y volcar los datos de la base de datos antigua a la nueva, y despues renombrar.

Asi no hay que bajar inumerables scripts.
Eso si, en caso de un gran numero de datos, puede tardar, pero en ningun caso puede haber problemas por que el usuario apague el equipo, ya que hasta que no pasan todos los datos no doy el "cambiazo" a la base de datos.

[afxe]

Hola de nuevo.

Esa idea también se me cruzó, pero tuve que desecharla, en primer lugar porque mis clientes sí tienen BD cargaditas y las actualizaciones se realizan frecuentemente, pero la principal razón son las tablas automantenidas. Ciertas tablas, como la de acumulados estadísticos, stocks por almacenes, control de género malo y envases, comisiones a vendedores, saldos periodicos de cobros y pagos, gestión de cartera, etc... son mantenidas por triggers. Es decir, si hago un volcado de datos, esas tablas se van a crear y mantener solas, por lo cual debía controlar de qué tablas hago volcado y de cuales no, o desactivar triggers a diestro y siniestro antes de dicha operación... pero hay más: algunas tablas, como la que me gestiona la cartera de efectos, las altas son automantenidas cuando en el fichero de cobros y pagos se realiza algún movimiento con efecto (talon, pagaré, recibo, etc...), sin embargo, luego son modificadas por el usuario (fecha de cobro, numero de remesa bancaria, estado de los efectos, gastos de devolución, etc...). En definitiva, además de ser lento, tendría que controlar la ejecución de triggers manualmente y, además, por ejemplo, si tenía que crear un campo nuevo, digamos "RiesgoDeImpago" (Char de 1) en el fichero de "Clientes" e inicializarlo con un valor "S" si la suma de importes en el fichero de "PendienteDeCobro" de ese cliente superaba los 6000 euros, y a "N" en caso contrario, tendría que mandar un script de todas maneras, con lo cual no me quitaba el problema.