11 respuestas en este tema

[razadi]

Saludos amigos, tengo una dudilla, no sé si se pueda, ahi va:

Tengo una base de datos "base 1" que esta trabajando en un lugar, ahora creo una nueva base "base 2" de donde requiero grabar ciertos registros de la base 1, pero sólo cuando en la base 1 sea agregada o modificada, en una tabla.

Ahora lo podría hacer desde la "base 1" directamente poniendole un control de evento, pero no! lo quiero controlar desde la base 2.

Espero no haber ]"cantinfleado"

Resumo...Quiero saber en que momento se agrega un registro en la base1, desde la base2.

de antemano gracias por su apoyo, saludos.

[egostar]

, la neta del planeta si cantinfleaste amigo, pero veamos, lo único que se me ocurre es que leas dentro de algún timer la Base1 para ver si hay algún cambio en la Tabla que quieres monitorear, no veo otra forma que no sea con eventos dentro de la Base1.

Salud OS

[Rolphy Reyes]

Saludos.

Eso que andas buscando no es posible desde el motor de Firebird en esa versión.

La versión 2.5 trajo como mejora la conexión entre BD desde el motor; ahora bien, no te puedo asegurar que las operaciones Insert/Update/Delete funcionen adecuadamente.  Todavía no lo tengo instalado.

P.D. Eso de "base 1" y "base 2" supongo que son Bases de Datos independientes, de ser tablas entonces utiliza triggers.

[razadi]

, la neta del planeta si cantinfleaste amigo, pero veamos, lo único que se me ocurre es que leas dentro de algún timer la Base1 para ver si hay algún cambio en la Tabla que quieres monitorear, no veo otra forma que no sea con eventos dentro de la Base1.

Salud OS

jajaja, "se me chispoteo", es que luego los clientes preguntan cada cosa y se le pega a uno...
Entonces no hay forma de que por eventos en la base2 pueda monitorear la base1???

Saludos.

Eso que andas buscando no es posible desde el motor de Firebird en esa versión.

La versión 2.5 trajo como mejora la conexión entre BD desde el motor; ahora bien, no te puedo asegurar que las operaciones Insert/Update/Delete funcionen adecuadamente.  Todavía no lo tengo instalado.

P.D. Eso de "base 1" y "base 2" supongo que son Bases de Datos independientes, de ser tablas entonces utiliza triggers.

ok amigo, lamentablemente no hay forma de cambiar, y si son bases independientes, voy a ver como lo dice egostar, gracias por su pronta respuesta a los dos

saludos.

[Delphius]

Efectivamente, como te han comentado, F1.5 no soporta acciones "cross-database" Recién desde la 2.5 se han implementado algunas de éstas posibilidades.

No te sabría decir si es que efectivamente se puede hacer lo que buscas, aprovechando el uso de triggers y eventos como señalas. De lo que tengo entendido, es que lo máximo que se puede hacer cross-database es consultas como:

sql

SELECT ... db1.tabla1, db2.tabla2

Pero de allí en más que los triggers y eventos tengan alcance fuera y acceder a otras bases de datos ha decir verdad no estoy seguro. De lo que si he oído es que existen triggers a nivel DB pero de que puedan acceder a una tercera... tengo mis reservas.

El punto es que la 2.5 es una versión de transición hacia FB3 y allí recién se espera tener un mejor soporte cross-database.

Lo más que puedes hacer es consultar en la db1 los cambios, guardar los datos de interés temporalmente, cerrar la conexión con db1, abrir una nueva con la db2 y realizar dichas inserciones con los datos temporales.

Saludos,

[Marc]

Como dice Rolphy, eso solo lo podrás hacer actualizándote a Firebird 2.5.

Con esa versión de Firebird puedes poner un trigger en la BBDD 1 para que cada vez que se modifique algún registro de una tabla, eso pueda ser actualizado a la BBDD 2.

Si no puedes cambiarte a Firebird 2.5, entonces necesitarás hacerlo escribiendo un programa externo, que consulte cada cierto tiempo la BBDD 1 y vaya registrando los cambios en la BBDD 2.

Edito: veo que mientras escribía ya lo habéis solventado.

Saludos.

[Caral]

Hola
Pregunto:
Por que no solo una Base de datos ?
Saludos

[Delphius]

Como dice Rolphy, eso solo lo podrás hacer actualizándote a Firebird 2.5.

Con esa versión de Firebird puedes poner un trigger en la BBDD 1 para que cada vez que se modifique algún registro de una tabla, eso pueda ser actualizado a la BBDD 2.

¿Se puede hacer eso amigo en 2.5? 
Ya verdad es que poco recuerdo de lo que leí de las novedades de esta versión de Firebird... como no me he documentado apropiadamente sobre 2.x ya estoy perdido de hasta donde llega la implementación cross-database.

Recuerdo que es posible realizar consultas, pero ¿inserciones mediante triggers y lanzar eventos? 

Saludos,

[razadi]

Hola
Pregunto:
Por que no solo una Base de datos ?
Saludos

lo mismo le pregunte al usuario, es un sistema ya hecho, de hecho todavia tiene interacciones con paradox, por eso quieren la segunda base de datos pero no quieren moverle a la base1, no entiendo....

de cualqueir forma muchas gracias, si voy a tener que hacer un sistema externo que me permita leer la base1 y cuando encuentre algo hacer el insert en la base2

[Marc]

Hola Delphius.

Como dice Rolphy, eso solo lo podrás hacer actualizándote a Firebird 2.5.

Con esa versión de Firebird puedes poner un trigger en la BBDD 1 para que cada vez que se modifique algún registro de una tabla, eso pueda ser actualizado a la BBDD 2.

¿Se puede hacer eso amigo en 2.5? 
Ya verdad es que poco recuerdo de lo que leí de las novedades de esta versión de Firebird... como no me he documentado apropiadamente sobre 2.x ya estoy perdido de hasta donde llega la implementación cross-database.

Recuerdo que es posible realizar consultas, pero ¿inserciones mediante triggers y lanzar eventos? 

Saludos,

Sí, no veo que tenga que haber ningún problema (es más, tengo pendiente programar algo por el estilo, pero aún no he podido hacerlo por falta de tiempo).

En la BBDD 1 pones un trigger para monitorizar una tabla.

En el cuerpo del trigger deberás incluir un comando EXECUTE STATEMENT con el correspondiente parámetro para que se ejecute sobre la segunda BBDD, y que lance una sentencia INSERT o UPDATE para actualizar la Tabla de Logs que quieras mantener sincronizada (los datos a insertar/actualizar, se le pueden pasar al EXECUTE STATEMENT como parámetro).

Saludos.

[Delphius]

¡Cierto! Me había olvidado que habían potenciado la cláusula EXECUTE STATEMENT, la verdad es que no se me ocurrió pensar en eso.

Esto demuestra lo mucho que me falta aprender de FB.

Saludos,

[Sergio]

Existen varias soluciones para replicacion http://www.firebirdfaq.org/faq249/, algunas gratuitas y con source code http://www.meta.com....structure_id=40, pero todas funcionan igual (y lo hacen asi desde las primeras versiones de FireBird):

1) En cada tabla a replicar se crean trigger para insert, update y delete que, al ocurrir, dejan logeado lo que ha ocurrido en forma de instruccion SQL equivalente en una tabla especial de lineas de texto.

2) Un proceso en el servidor monitorea esta tabla, normalmente con un event listener que salta cada vez que la tabla se modifica (no tiene que estar mirando cada 5 segundos), y cuando salta, lee las nuevas lineas añadidas y las ejecuta tal cual en la base de datos replicada, donde tiene guardado el ultimo IdLinea ejecutado (asi se puede actualizar una replica antigua cuando queramos, ya que tiene guardada cual fue la ultima instruccion que se aplico de la lista de cambios).

Si ahora con FB 2.5 se puede hacer directamente en los triggers de la BD1 alterando la DB2 al vuelo, lo desconozco, pero quizas sigua siendo mejor el proceso "clasico", ya que tienes un log de cambios que puedes aplicar a cualquier base replicada antigua y ponerla al dia, te perimte replicar en 5 copias a la vez, e incluso hacerlo en las dos direcciones (en ese caso pueden ocurrir bloqueos: si yo borro algo aqui, y otro lo modifica alli, cuando estas dos intrucciones se crucen, segun en que orden se haga puede saltar un error al modificar algo ya borrado y esas cosas).

NOTA1: El punto debil de este sistema es cuanod se produce un cambio en la estructura de la BD, si ese cambio no se logea "a mano" en la lista de cambios a propagar, la BD2 se queda anticuada y las cosas empiezan a ir mal, y si hacemos el cambio en la BD2 manualmente, entonces el problema es que debemos hacerlo cuando esa BD2 este en el mismo punto que estaba la BD1 o de nuevo tenemos problemas... vamos, que toca insertar esos cambios como instrucciones SQL en la listya a mano, luego hacerlos en la BD1, y el proceso de replicacion lo clonara en BD2 en el orden correcto.

NOTA2: La pregunta incial era si se puede hacer desde la BD2, y creo que la respuesta, incluso usando FireBird V3, es que no: DB2 no tiene acceso a los eventos que ocurren en la BD1, que incluso podria (y normalmente esta) en otro servidor de BackUp, siempre seria desde DB1 que es el que recibe sus eventos.