Actualización de bases de datos remotas.

[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.