8 respuestas en este tema

[jmartiza]

Saludos

Estoy evaluando el uso del Ib Replicator para un sistema que seria usado en 4 puntos geograficos distintos
1 en la ciudad donde estan las oficinas administrativas,  y 3 rurales las cuales obtienen el intenet por medio de
antenas de  microondas del centro urbano mas cercano, lo cual produce que la disponibilidad del internet no sea una garantia

creo que la mejor opcion puede ser que cada punto tenga una copia de la base de datos y se esten sincronizando por medio del
IbReplicator.

aparte de su opinion y experecnia en este tema la otra cuestion es es tipo de dato para las llaves primarias
las opcion seria usar vchars o char para almacenar valores GUID para asegurar la integridad de los datos
o bien de acuerdo aun articulo que lei de otro replicador australiano.
http://www.meta.com....structure_id=40

donde sugieren que cada sitio tenga su semilla
ejemp sitio 1 pues semilla 1
sitio 2 semilla 2
y asi sucesivamente y que el valor de los brincos de las llaves sea de 10000 en 10000
eejmplo el sitio 1 sus llaves se irian asi
10001
20001
30001
y del sitio 2
10002
20002
30003

asi nunca chocarian los ids primarios 

saludos a todos espero ampliar mas en base a sus comentarios

[Sergio]

No mezcles semilla e id en un solo campo, se te puede "llenar" y no cabertte mas registros: usa mejor claves de dos campos tipo "primary key semilla, Id", asi evitas que al llegar a un Id alto ya no te quepa la semilla.

[Marc]

Hola.

Yo en mis sistemas en replicación (tengo un replicador propio) utilizo el sistema de semilla e ID. Pero en lugar de generar SITIO + CONTADOR, yo genero la clave a partir de CONTADOR + SITIO. Es decir, para el sitio 1, las claves serían :

101
201
301
401
...
...
32201
32301

Para el Sitio 2 :

102
202
302
...
..

Tiene el inconveniente de que no puedo configurar más de 99 puntos en replicación (aunque no necesito tantos puntos, en caso contrario utilizaría 3 dígitos para tener hasta 999 puntos), pero con la ventaja de que no se te pueden agotar los códigos, como bien comenta Sergio.

El tema de utilizar GUID es una buena idea, pero la verdad es que es un poco incómodo manejar una base de datos con claves primar GUID (no es inmediato ver los registros en orden de inserción, y es incómodo lanzar manualmente consultas que busquen un determinado registro o grupos de registros, ya que las claves primarias son largas de escribir y casi imposibles de recordar).

Para programar mi replicador me basé en este documento, que es todo un clásico (aunque con mis propias mejoras aprovechando las nuevas características de Firebird).

http://www.ibphoenix.../how_to/doc_316

[jmartiza]

Yeahhh...
Gracias por sus respuestas en verdad que este esfuerzo de delphiacces me regresa la fe en mi mismo y las capacidades del delphi.

Ok reafirmando sus ideas y a las mias creo que lo de que cada sitio tenga su semilla y bincos de 100 es mas que suficiente
ademas de que no tendre que cambiar el diseño de mi base de datos.

otra duda que me surge es como manejar las inserciones de  los registros que se crean a partir de triggers de "negocio"
ejemplo
cuando el usuario graba un "albarran" "factura" de credito yo disparo la creacion en una tabla separada donde llevo los pagare de credito
esta insercion deberia de ser replicada o que la misma accion de la replicacion cree ese registro en la tabla destino

de igual forma por ejemplo con los cambios de existencia
en mi tabla de movimientos de inventario en mis triggers de "negocio" voy y afecto mi tabla donde tengo las existencia por almacen.
Los cambios de las existencias deben de replicarse o edjar que la accion de el triger en al tabla destino lo reaize....?

saludos.

[Sergio]

Supongo que el proceso de replicar deberia desconectar los triggers en la tablas receptora antes de traerse nuevos registros o modificaciones, asi te fias de que los triggers de la base de datos origen hicieron su trabajo y en el destino solo copias el resultado de esa insercion, con todos sus cambios y altas secundarias.

Supongo que Marc te puede dar una respuesta con mas fundamente, pero es lo que yo haria asi a "bote pronto".

[Marc]

Hola.

Opino como Sergio, yo también lo hago de esa forma (es lo más sencillo y te vas a ahorrar posibles problemas, puesto que imagina que las reglas de negocio te rellenan una tabla auxiliar, si en lugar de replicar esa tabla auxiliar dejas que la rellenen las reglas de negocio durante la replicación, te encontrarás con que sus claves primarias serán distintas en todas las ubicaciones y por tanto el sistema no podrá propagar entre ubicaciones cualquier modificación que se haga posteriormente a esa tabla auxiliar).

Para desactivar todos los Triggers de Reglas de Negocio durante el proceso de replicación, solo tengo que añadir esta línea al principio del Trigger :

IF (current_role = 'REPLICADOR') THEN EXIT;

Para ello el sistema debe tener definido este rol REPLICADOR, y la conexión que utiliza el ejecutable de Replicación debe conectarse usando este Rol. De esta forma, cuando incorporas los registros replicados no se dispararán los triggers de las Reglas de Negocio.

NOTA: El documento que te he enlazado antes utiliza un usuario REPLICATE para desactivar las reglas de negocio :

IF (USER <> "REPLICATE") THEN

Pero personalmente prefiero usar un Rol, puesto que de esta forma no tengo que recordar de asignar derechos al usuario REPLICATE sobre todas las tablas que voy creando.

Saludos.

[jmartiza]

Ok si coincido con lo de los registros hijos que se crean... definitiva,nete se perderia su identidad al crearse tambein en el destino... al tener dfernets id

pero en el caso de las tablas de arrastre de saldos como el de las existencias de un inventario ...
tal vez esas si tengan que verse afectada por el triger del destino.
porque si no cuando se defase la replicacion por falta de conexion se podria planchar un saldo dando un dato irreal.

entonces talvez cuando la tabla sea de tipo "acumulador" si se vea afectada pro los triggres de los movs de inventario....

[Marc]

Ok si coincido con lo de los registros hijos que se crean... definitiva,nete se perderia su identidad al crearse tambein en el destino... al tener dfernets id

pero en el caso de las tablas de arrastre de saldos como el de las existencias de un inventario ...
tal vez esas si tengan que verse afectada por el triger del destino.
porque si no cuando se defase la replicacion por falta de conexion se podria planchar un saldo dando un dato irreal.

entonces talvez cuando la tabla sea de tipo "acumulador" si se vea afectada pro los triggres de los movs de inventario....

Sí, puedes hacerlo.

Aunque está claro que lo que resulta más fácil de implementar es desactivar las reglas de negocio durante la replicación y dejar que los efectos de esas reglas de negocio se propaguen mediante la replicación, como cualquier otra tabla y campos. Pero a veces puedes ser más flexible y añadir alguna regla de negocio puntual que se ejecute también durante la replicación de alguna/s determinada/s tabla.

Personalmente yo no lo hago. Entre otras cosas porqué los acumuladores más críticos (como por ejemplo el STOCK) no los mantengo en tablas sino que los calculo cada vez que necesito consultarlos. Con los índices bien afinados, el cálculo de stock de un producto a partir de sus albaranes de compra, de venta, regularizaciones, etc. ... es muy rápido, incluso cuando cargo en pantalla 5.000 productos con sus respectivos stocks.

Pero esta claro que una de las ventajas de construirte tu propio replicador es que lo puedes personalizar a tu gusto. Y en ese caso puedes hacer que la tabla del acumulador de stock por producto y por tienda (ubicación/almacén/...)  no se replique mediante el motor de replicación, sino que sea actualizado directamente por reglas de negocio, incluso durante la misma replicación.

Eso ya depende mucho de cada situación.

Saludos.

[jmartiza]

Gracias por sus aportes puntuales a mis dudas especificas.

Espero tenerles noticias de este proyecto que estoy por empezar .

usare el ibreplicator pues la carga de trabajo no me da para implementar mi propio replicador aun
cuando conceptualmente lo comprendo..