Club Delphi  
    FTP   CCD     Buscar   Trucos   Trabajo   Foros

Retroceder   Foros Club Delphi > Bases de datos > Firebird e Interbase
Registrarse FAQ Miembros Calendario Guía de estilo Buscar Temas de Hoy Marcar Foros Como Leídos

Respuesta
 
Herramientas Buscar en Tema Desplegado
  #1  
Antiguo 24-08-2003
ElSanto24 ElSanto24 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Elche
Posts: 14
Poder: 0
ElSanto24 Va por buen camino
porqué es tan dificil actualizar la informacion en interbase?

Hola a todo el mundo que lea esto:

Soy un verdadero newbie en esto de postear en foros y mas newbie todavia en lo que se refiere a desarrollos clientes/servidor en delphi...desgraciadamente me he visto obligado a dar un salto cuantitativo desde delphi3 y sus tablas paradox a Delphi 7 e interbase para hacer algo serio...así que he de reciclarme en poco tiempo y, aunque lo hago de buena gana y he leido mucha documentacion que me ha servido bastante (la cara oculta de delphi) pues aun me surgen cantidad de dudas que si alguien ya ha resuelto me gustaria que me ayudara y de todo corazón se lo agradeceré:

La interfaz de mi aplicacion ya está hecha así que para mi aprendizaje estoy haciendo pruebas con tan solo una tabla, cuando mis dudas desaparezcan...continuaré con seguridad el resto de la aplicacion (una filosofia como otra cualquiera...creo yo)

En fin...ahí va mi duda!


Tengo una tabla que tan solo tiene 2 campos, uno que es el CodId y otro que es descripcion, CodId es la pkey.
He creado un generador para crear autovalores para codId y el procedure asociado que llama a gen_id(nombregenerador,incremento)....hasta ahí todo es correcto.

En cuanto a los componentes que utilizo, tengo un database que se engancha con mi BD,un ibtransaction enganchado al database,un ibdataset enganchado al database y al ibtransaction, un ibstoredproc para poder obtener el valor del autoincremental (CodId), y finalmente tengo un datasource que engancha con los VCL´s (en este caso un par de dbedits y un dbgrid).

En fin....defino para el ibdataset los campos selectsql modifysql deletesql insertsql y REFRESHSQL (lo pongo en mayusculas porque este es el origen de mi quebradero de cabeza)

he leido que para rellenar la sentencia refreshsql debo hacer algo como
select * from MItabla
where CodId=:CodId (otra version de lo mismo: where CodId=:new_CodId)

El problema es QUE NO ACTUALIZA LA INFORMACIÓN!!!!!
es decir....
en el afterpost y afterdelete hago uso de los commitretaining etc...tal y como he leido en otros foros y en la cara oculta...

Abro mi aplicacion 2 veces en mi maquina (simulando concurrencia o si dos clientes atacaran a mi server) cuando modifico la info de la tabla, la guardo, en esa ventana la info aparece, pero sin embargo en la ventana del "otro usuario" no aparece ni siquiera cuando le doy tb a refresh, (teniendo en cuenta que se ha llamado a commit)....cual es el problema de esto?????

Tambien he leido que utilizando post_events y triggers se podria obtener el mismo resultado porque cuando actualizas el server (after update) se supone que lanza el trigger y ahí se supone que lanzará el evento (tengo insertado el componente ibEventAlerter que se supone que capturará el evento y que me permitirá hacer lo que me plazca....) PUES NOP!!!! es como si el evento nunca se lanzara porque pongo como prueba showmessages y no los visualiza (en el evento EventAlert del componente) y he configurado correctamente (creo el componente)

Alguie podria arrojar luz a esta gran duda que me preocupa??? por qué no funciona???? hay alguien que haya necesitado actualizar la informacion y el refesh le funcione o el post_event??? si fuera así....por favor, escribidme a mi mail o por aki como lo haceis porque de verdad estoy bastante preocupado al no saber ninguna alternativa a todo esto.

Os voy a poner el código que tengo implementado, a ver si quizas el problema sea que no lo estoy escribiendo bien:

procedure TFFPago.FormCreate(Sender: TObject);
begin
ibtransaction1.StartTransaction;
ibdataset1.Close;
ibdataset1.Open;
ibevents1.Registered:=true;
end;

procedure TFFPago.FormDestroy(Sender: TObject);
begin
if ibtransaction1.InTransaction then
ibtransaction1.commit;

end;

procedure TFFPago.IBDataSet1AfterInsert(DataSet: TDataSet);
begin
ibstoredproc1.ExecProc;
ibdataset1codId.Value:=ibstoredproc1.Params[0].asinteger;
end;


procedure TFFPago.IBDataSet1AfterPost(DataSet: TDataSet);
begin
try
ibtransaction1.CommitRetaining;
except
ibtransaction1.RollbackRetaining;
end;
end;

procedure TFFPago.IBDataSet1AfterDelete(DataSet: TDataSet);
begin
try
ibtransaction1.CommitRetaining;
except
ibtransaction1.RollbackRetaining;
end;
end;

procedure TFFPago.IBEvents1EventAlert(Sender: TObject; EventName: String;
EventCount: Integer; var CancelAlerts: Boolean);
begin
ibdataset1.close;
showmessage('cierro');
ibdataset1.open;
showmessage('abro?');
end;


Gracias a todos los que leais este post por vuestro interes y gracias en especial a quien me pueda ayudar con este tema
Un saludo
__________________
El camino para llegar al conocimiento de las cosas pasa por el aprendizaje humilde de lo que nos rodea
Responder Con Cita
  #2  
Antiguo 24-08-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola ElSanto24,

Cita:
Posteado originalmente por ElSanto24 Soy un verdadero newbie en esto de postear en foros ...
Pues bienvenido a estos foros. Por cierto, excelente mensaje: buena presentación en el foro y detallada descripción del problema ... perfecto.

Cita:
Posteado originalmente por ElSanto24 Abro mi aplicacion 2 veces en mi maquina (simulando concurrencia o si dos clientes atacaran a mi server) cuando modifico la info de la tabla, la guardo, en esa ventana la info aparece, pero sin embargo en la ventana del "otro usuario" no aparece ni siquiera cuando le doy tb a refresh, (teniendo en cuenta que se ha llamado a commit)....cual es el problema de esto?????
Solo se me ocurre que sea un asunto del nivel de aislamiento de la transacción. El componente TIBTransaction toma por defecto el valor "Snapshot". Con ese nivel de aislamiento, la transacción no puede "ver" los cambios que hagan otras transacciones concurrentes, incluso las confirmadas (commit). Si es el caso, prueba a bajar el nivel de aislamiento a "Read-Commited".

Saludos.
Responder Con Cita
  #3  
Antiguo 24-08-2003
ElSanto24 ElSanto24 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Elche
Posts: 14
Poder: 0
ElSanto24 Va por buen camino
Gracias por la calida bienvenida....pero no creo que merezca el elogio de una buena explicación ....jejejeje porque precisamente en mi extensa explicacion del problema se me ha olvidado decir que efectivamente, el nivel de aislamiento (isolation) que tengo en el ibtransaction es Read-commited, eso significa mi estimado kinobi que, agradeciendo muchisimo tu post y de nuevo la calida bienvenida, tendré que seguir esperando a que alguien responda a esta llamada de SOCORROOOOOOOO jejeje
__________________
El camino para llegar al conocimiento de las cosas pasa por el aprendizaje humilde de lo que nos rodea
Responder Con Cita
  #4  
Antiguo 24-08-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

con un nivel de aislamiento "read_commited", el cierre y reapertura del Dataset debería permitir ver los cambios aplicados desde otra(s) transacción concurrentes, siempre que hayan sido confirmados (commit).

Un comentario: aunque dices, o eso creo entender, que cierras y reabres el Dataset, también haces referencia a "Refresh" (supongo que te refieres al método Refresh). En IBX el método Refresh no actualiza el Dataset, actualiza simplemente el registro actual "activo" del Dataset.

Respecto al asunto de los eventos InterBase: es necesario registrar en TIBEvents los eventos que quieres capturar ...

Código:
MisEventosIB.Events.Add('Evento');
MisEventosIB.RegisterEvents;
Y por último, asegúrate de estar trabajando con la última versión de IBX. Si no la tienes puedes descargarla de ...

http://codecentral.borland.com/codec...r?authorid=102

Saludos.
Responder Con Cita
  #5  
Antiguo 25-08-2003
ElSanto24 ElSanto24 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Elche
Posts: 14
Poder: 0
ElSanto24 Va por buen camino
Lightbulb

valeeeeeeeeeeeeeeeeeeeeeeee tio!!!! jejejejejejeje ya lo he lograo!!!!!

lo comento para la gente que esté en la misma situación que yo....

Este trozo de mensaje va destinado a esos resignados programadores en delphi que ven como su tiempo de desarrollo se alaaaarga por "chorradas" (jejeje ahora puedo decirlo) como esta....no se si os ocurre, pero cuando estais dias intentando solucionar problemas aparentemente sencillos y nadie consigue ayudarte y tan solo te dan pistas pues....frustra un poco...y el subidon cuando despues de todo el tiempo estrujando las pocas neuronas que la pantalla te deja despues de horas delante....consigues "aparentemente" y a falta de que algún Master de delphi /interbase me corriga (dios mio!!! espero que no!!) en fin...no me alargo más... aquí está la respuesta a las actualizaciones....seguid atentamente estos pasos!!!!

si leeis el primer mensaje que posteé...ahí decia como tenia configuardo todos los componentes, si algo no entendeis, estaré gustoso en explicaros con detalle...lo mas importante es:

Tal como dice el gran kinobi (gracias tio!!!...haces que uno se sienta a gusto escribiendo aki!!!) se supone que si el nivel de aislamiento es Read-commited solo con cerrar y abrir el dataset deberia actualizarse.....pero, amigo mio, en mi opinion lo dejas un poco en el aire....aquí está el codigo que hará funcionar el refresco de información para un puesto concurrente (otro cliente).

Ya leí con anterioridad que la forma de actualizar la info era cerrando y abriendo el dataset...pero como y donde meter ese cierre y apertura???

se me ocurrió como prueba poner un botón de cierre de dataset y otro de apertura para ver como funcionaba en sus entrañas...y efectivamente....reproduciendo los pasos de......
inserta registro...
actualiza su info...
grabalo (post, el codigo está en el anterior mensaje)
vete al otro cliente
cierra el ibdataset
abre el ibdataset

Solo con eso....veia como se cerraba la tabla y al abrirla la info estaba actualizada....eureka??? nop...todavia no...pq cuando queria meterme en el ultimo registro (last) me daba un mensaje de error (este ultimo caso no se si será solo a mi o si quien reproduzca estos pasos le ocurrirá lo mismo...siempre dije que era...alguien muy especial :P )....en fin...

Este mensaje lo conseguí eliminar haciendo la siguiente secuencia lógica
cierra...
abre....
refresh....
con ello...yendo al ultimo registro ya no daba el mensaje de error....ahora si.....EUREKAAAAAAAAAAAAAAAAAAAAAAAA!!!!!!

El ultimo escollo era saber donde meter esa secuencia de instrucciones para que todo funcionara ok...entonces pensé:
"bueno, mientras estoy editando nop.....no tiene sentido....sin embargo....cuando inserto un registro nuevo, si que seria interesante ver la info que hay en la tabla antes de editar el registro actual....eso me lleva al......BEFOREINSERT...aquí está el código

procedure TFFPago.IBDataSet1BeforeInsert(DataSet: TDataSet);
begin
ibdataset1.Close;
ibdataset1.open;
ibdataset1.refresh;
end;

mientras escribo estas palabras se me ocurre que tambien debo hacer esa actualización tanto en el beforedelete como en el beforecancel...beforerefresh.....no sé....he de madurar más la idea....pero valorad esa posibilidad, de momento el tema de la actualización está solucionado.......jejejejeje



Espero que este texto os sirva tanto como me sirve a mi...si es así...habrá merecido la pena haberlo escrito

Un saludo a todos los del foro (a los que conozco (pocos...a decir verdad....1 ) y a los que no conozco

Bye!
__________________
El camino para llegar al conocimiento de las cosas pasa por el aprendizaje humilde de lo que nos rodea
Responder Con Cita
  #6  
Antiguo 25-08-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

Cita:
Posteado originalmente por ElSanto24
procedure TFFPago.IBDataSet1BeforeInsert(DataSet: TDataSet);
begin
ibdataset1.Close;
ibdataset1.open;
ibdataset1.refresh;
end;
hace tiempo que no utilizo IBX, pero es la primera noticia que tengo sobre la necesidad de llamar al método Refresh para que actualice el último registro del Dataset tras el cierre y re-apertura del mismo.

Mañana lo miro con calma y hago una prueba.

Saludos.
Responder Con Cita
  #7  
Antiguo 25-08-2003
ElSanto24 ElSanto24 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Elche
Posts: 14
Poder: 0
ElSanto24 Va por buen camino
Hola de nuevo....

Ayer me embargaba la alegria por haber resuelto el problema de la actualización, pero me precipité a la hora de hacer el post....kinobi tiene razon, no hace falta hacer el refresh, de hecho tal y como lo puse en el anterior post llegaba a dar un error como el que sigue

"grid index out of range"
he leido en otros foros y comentan que eso es cuando vas a recorrer el dataset fila por fila suele ocurrir ese error y que la solucion es utilizar dataset1.disablecontrols dataset1.enablecontrols....pero es que esto no es un recorrido como tal...no se como delphi implementa el last...pero desde luego el error era fijo y lo podia reproducir siempre que quisiera cuando le daba a refresh (que en el metodo afterRefresh tenia escrito lo siguiente:
ibdataset1.close;
ibdataset1.open;
ibdataset1.last;
)

pues eso...al ejecutar eso me daba ese error (es el error que pretendia haber resuelto precisamente con el refresh y que está comentado en el post anterior (donde comento que "me daba un fallo pero no se si solo será a mi....siempre dije que era alguien muy especial") pues aquel fallo que comenté por encima era el mismo que ahora me salia "grid index out of range"...

aparentemente he solucionado el bug y de momento(solo de momento) no ha vuelto a fallar....los cambios que realicé

en lugar de afterRefresh he puesto lo siguiente en beforeRefresh
ibdataset1.close;
ibdataset1.open;

estas mismas dos lineas tb estan en el beforeinsert....

lo he puesto en estos dos metodos pq quiero ofrecer al usuario la posibilidad de ver su info actualizada tanto cuando inserte registro nuevo como cuando le de a refrescar (por si se le ocurriera hacerlo )

supongo que deberia controlar de alguna forma que un usuario que no ve la info actualizada no pudiera borrar, por ejemplo un registro que previamente otro usuario ya ha borrado....en fin...quien lea esto creo que tendrá la capacidad de saber de qué estoy hablando....


Un saludo a todo el mundo
__________________
El camino para llegar al conocimiento de las cosas pasa por el aprendizaje humilde de lo que nos rodea
Responder Con Cita
  #8  
Antiguo 25-08-2003
Avatar de guillotmarc
guillotmarc guillotmarc is offline
Miembro
 
Registrado: may 2003
Ubicación: Huelva
Posts: 2.638
Poder: 23
guillotmarc Va por buen camino
Hola.

No utilizo IBX por lo que no te puedo aconsejar sobre estos problemas.

Aunque lo que si quería comentar, es que me extraña que pongas el refresco en eventos Before. Lo que me parece más curioso es que funcione. O sea tienes un cursor, y al ponerlo en modo de inserción lo cierras y lo vuelves a abrir ¿ y esperas que el cursor sigua estando en modo inserción ?, ¿ y que ocurre con el registro activo en las modificaciones ?, ...

A mi modo de ver, la actualización del cursor la deberías hacer en los eventos After (AfterInsert, AfterPost, ...). En ese momento has pasado a la base de datos todos los cambios que te interesan, y puedes cerrar el dataset de forma segura.

Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).
Responder Con Cita
  #9  
Antiguo 25-08-2003
ElSanto24 ElSanto24 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Elche
Posts: 14
Poder: 0
ElSanto24 Va por buen camino
hola,

Sinceramente no se si la solucion que he adoptado es la mejor, imagino que no pues lo que dices tiene sentido, pero ahora mismo, y a falta de que alguien que si trabaje con ibx me corrija lo que hago es lo siguiente

en el beforeinsert efectivamente hago el refresco (entiendase como tal, cerrar y abrir)

en el afterinsert lo que hago es llamar al generador de la clave primaria de tal forma que consigo el siguiente efecto optico (no sé si será repito, la mejor forma de hacerlo, pero funciona...y hasta que no casque....he de sacar trabajo hacia delante.

cliente 1 cliente 2

inserta registro (edicion) /cliente2 no ve nada nuevo/
edita registro y graba /cliente2 no ve nada/
ve solamente su registro /cliente2 inserta registro/
/cliente2 (en momento ve que alguien ha
creado un registro nº 1 y el
formulario le dice que el
siguiente codigo del registro
que está editando es el 2)
que eso se consigue con el
generador de id´s/
cliente1: dos opciones
o bien refresh (veria que ahora hay 2 registros)
o bien insert ( y se repetiria la misma secuencia que para cliente2)

eso es hasta ahora lo que he conseguido, si es optima la forma de hacerlo .....no lo sé...pero ya te comento....hasta que no aparezca un Master de delphi/interbase con dilatada trayectoria (almenos más de unos meses como tengo yo...soy un bebé) pues...si me corrige o me sugiere otra forma de hacerlo...estaré gustoso en leerle con toda mi atencion...


Un saludo
__________________
El camino para llegar al conocimiento de las cosas pasa por el aprendizaje humilde de lo que nos rodea
Responder Con Cita
  #10  
Antiguo 25-08-2003
Avatar de guillotmarc
guillotmarc guillotmarc is offline
Miembro
 
Registrado: may 2003
Ubicación: Huelva
Posts: 2.638
Poder: 23
guillotmarc Va por buen camino
Hola.

Es bastante habitual tratar el problema de las actualizaciones, mediante eventos de Interbase.

Se definen unos eventos en la base de datos, y se añaden unos triggers en las tablas que se modificaran. En los triggers, programamos que se dispare el evento correspondiente al insertar o modificar un registro.

Ahora solo tienes que poner un componente IBEvent en tu formulario, de forma que se de cuenta de cuando se dispara un evento en la base de datos, y actualizar los datos para mostrar los datos modificados.

Esta forma de trabajar es un poco laboriosa, pero tiene la ventaja de que cuando un usuario introduzca un registro, automaticamente todos los usuarios verán el cambio.

Si buscas en el histórico de mensajes de este Foro (y en los antiguos Foros), encontrarás varios mensajes donde se detalla mejor este proceso.

Saludos.
__________________
Marc Guillot (Hi ha 10 tipus de persones, els que saben binari i els que no).

Última edición por guillotmarc fecha: 25-08-2003 a las 15:01:23.
Responder Con Cita
  #11  
Antiguo 26-08-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

Cita:
Posteado originalmente por ElSanto24 ... eso es hasta ahora lo que he conseguido, si es optima la forma de hacerlo .....no lo sé...
es que no existen muchas más formas. Todo pasa por enterarte de que ha ocurrido un cambio desde otra(s) transacción (por ejemplo con TIBEvents) y relanzar la consulta que alimenta al Dataset. Como hemos comentado, las transacciones deben tener un nivel de aislamiento que permita ver los cambios que aplican unas y otras.

Ahora bien, trabajar en un entorno cliente/servidor y que desde los clientes se tenga constancia (de forma automática) de lo que está sucediendo (en tiempo real) en el servidor significa asumir:

1. Un sistema complejo de actualización de los Datasets en el cliente. No sólo en los eventos de los Datasets, también en los eventos (eventos InterBase, IBEvents) que se lanzan desde el servidor. Una simple actualización de una tabla en el servidor, puede provocar que se active (tal vez innecesariamente) en cascada varias veces el mecanismo de refresco en los clientes si desde algún trigger se "tocan" otras tablas que lancen eventos.

2. Un tráfico de red creciente. Con pocos clientes puede no ser preocupante, pero tampoco es necesario irse a grandes instalaciones para que el sistema se haga inmanejable.

Otra cuestión es que los Datasets y los controles enlazados a éstos están pensandos para ese tipo de aplicaciones, heredado de los primeros tiempos del BDE, pensando en motores de datos navegacionales, aunque después se diera soporte para motores cliente/servidor.

Saludos.
Responder Con Cita
  #12  
Antiguo 26-08-2003
ElSanto24 ElSanto24 is offline
Miembro
 
Registrado: ago 2003
Ubicación: Elche
Posts: 14
Poder: 0
ElSanto24 Va por buen camino
Hola,

Tal y como posteé en uno de mis primeros mensajes, ya intenté utilizar post_events y creé el trigger asociado after update, e incluso en el componente hice un ibevents1.add("evento") e ibevents1.registerEvent (lo estoy recordando de memoria asi que disculpadme si no es fiel a la realidad el nombre del procedure) tal y como kinobi ya me recomendó en otro post.....pero nada....no hacia nada.....tenia el nivel de aisalmiento a read-commited, hacia comitretaining en el afterpost y nada...el trigger pasaba de mi....por eso estaba tan desesperado hasta que encontré esta alternativa...sé que de la otra forma es más eficiente, pero esta es la forma que ha funcionado...y esa es la que utilizo....de todas formas, ahora me acabo de encontrar con otro problema....os hago una descripcion y a ver si alguien me pudiera ayudar, aunque, si ninguno de los dos trabajais recientemente con ibx no sé...quizas os suena de qué puede ser:

cuando estaba haciendo las pruebas y una vez que me aseguré que todo funcionaba ok, decidí poner todos los comonentes no visuales en el form principal por....limpieza, así pues teniendolos en el form principal, reescribo todo el codigo para que enlace con este formulario. lo que ocurre es que ahora cuando abro la ventana que en su momento funcionó bien, pues...cuando abro la primera vez no ocurre nada y puedo insertar registros....cuando salgo y vuelvo a entrar me da un mensaje tal que así

Transaction is active

ahora mismo (en el momento de escribir este post) estaba en ello, pero si de todas formas teneis alguna idea...será bienvenida


Un saludo, bye
__________________
El camino para llegar al conocimiento de las cosas pasa por el aprendizaje humilde de lo que nos rodea
Responder Con Cita
  #13  
Antiguo 26-08-2003
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Hola,

empiezo por el final ...

Cita:
Posteado originalmente por ElSanto24
...cuando abro la primera vez no ocurre nada y puedo insertar registros....cuando salgo y vuelvo a entrar me da un mensaje tal que así

Transaction is active
Si estás controlando explícitamente el arranque (StartTransaction) y cierre (Commit o Rollback) de las transacciones, lo más probable es que al salir la primera vez del formulario te dejes la transacción sin cerrar y al volver a entrar intentas re-arrancarla.

Cita:
Posteado originalmente por ElSanto24
...sé que de la otra forma es más eficiente, pero esta es la forma que ha funcionado...y esa es la que utilizo...
Personalmente no encuentro eficiente ninguna de las formas. Y no porque desconfíe de tu habilidad, al contrario, sino porque lo que pretendes no tiene, bajo mi punto de vista, una buena solución.

Si el mecanismo de refresco lo activas desde el cliente, por medio de los eventos de los Datasets, estarás provocando que se reabran las consultas, en muchos casos tal vez innecesariamente.

Si lo haces desde el servidor, por medio de los TIBEvents, estás en una situación similar. Los eventos Interbase son un mecanismo muy simple de comunicación servidor/cliente. "Simplemente" (ojo a las comillas) puedes saber que se ha producido un suceso en el servidor; en el mejor de los casos de qué tipo (inserción, actualización o borrado) y en que momento (antes o después de), pero no sabes cuantas filas se ven afectadas, ni cuales.

Una posible solución es subir el sistema a una arquitectura de tres niveles y que se encargue de activar los procesos de refresco en los clientes un servidor de datos intermedio. Este servidor de datos sería el único que mantendría una conexión directa con el servidor Interbase. Cuando se produzca una actualización de datos, el servidor InterBase "avisaría" al servidor de datos que, conociendo el estado de cada uno de los clientes, podría activar, si fuese necesario, el refresco de los datos en los mismos, ya que el servidor de datos intermedio sí puede saber que datos concretos han cambiado.

Un esquema ...

Código:
                                                  -----------
                                               /-- Cliente-1
                                              /   -----------
                                             /
                                            /     -----------
BD1 -                                      /   /-- Cliente-2
     \                  ----------  (2)   /   /   -----------
BD2 - \----------  (1)   Servidor -------/   /
     \- Servidor -------  Datos   ----------/     -----------
BD3 ---  IB/FB                    ---------------- Cliente-3
 .    /----------         Proxy   ------\         -----------
 .   /                  ----------       \
 .  /                                     \            .
BDn/                                       \           .
                                            \          .
                                             \
                                              \   -----------
                                               \-- Cliente-n
                                                  -----------
                                                  
(1) El servidor Proxy mantiene varias conexiones con el 
    servidor InterBase/Firebird, al menos tantas como con
    bases de datos esté conectado. Una conexión del Proxy
    con el servidor InterBase/Firebird puede dar servicio
    a varios clientes.
    
    El servidor IB/FB "avisa" (p. ej. IBEvents) al Proxy 
    de los cambios que se produzcan en la(s) base de 
    datos. El Proxy, que conoce los cambios "concretos" 
    que se han producido, determina que clientes deben 
    refrescar sus datos.

(2) Los clientes mantienen tantas conexiones con el
    servidor Proxy como sea necesario. En todo caso, los
    clientes nunca se conectan directamente con el
    servidor IB/FB.
Desde luego no es algo trivial, y es necesario pensar en tecnologías distribuidas.

Saludos.
Responder Con Cita
  #14  
Antiguo 10-09-2003
jourdan jourdan is offline
Miembro
 
Registrado: may 2003
Ubicación: Mexico
Posts: 151
Poder: 21
jourdan Va por buen camino
encontre aqui un poco de información sobre las actualizaciones de datos:

http://www.firebird.com.mx/articulos/pdox_a_ib-7.php

Saludos

AJ
__________________
Alejandro Jourdan
Responder Con Cita
  #15  
Antiguo 01-03-2004
SyncMaster SyncMaster is offline
Miembro
 
Registrado: mar 2004
Posts: 15
Poder: 0
SyncMaster Va por buen camino
¿Y los Triggers?

Creo que es mucho mas facil usando los famosos disparadores de eventos. Lean este articulo :

http://www.interbase.com.mx/articulo..._interbase.php
Responder Con Cita
  #16  
Antiguo 01-03-2004
Avatar de kinobi
kinobi kinobi is offline
Miembro
 
Registrado: may 2003
Posts: 2.621
Poder: 23
kinobi Va por buen camino
Cita:
Empezado por SyncMaster
¿Y los Triggers?

Creo que es mucho mas facil usando los famosos disparadores de eventos. Lean este articulo :

http://www.interbase.com.mx/articulo..._interbase.php
Sí, el uso de triggers y eventos InterBase lo hace más simple, pero el problema está en controlar el asunto.

Imagina que lanzas un evento por cada vez que se elimina un registro de una tabla, y desde tu aplicación cliente "refrescas" el Dataset (sea un TTable, TQuery, TIBTable, ...) asociado a esa tabla capturando ese evento. Ahora imagina que pasas una sentencia SQL al servidor que borre (DELETE FROM <tabla> WHERE <condición>) pongamos por ejemplo 10.000 registros de esa tabla ... el caos que puedes provocar en la red de ese sistema será grandioso, ya que por cada registro provocarás que se lance el evento y se refresque (¡10.000 veces!) el DataSet asociado en todas las aplicaciones clientes que tengan ese DataSet abierto.

El uso de eventos+triggers puede ser adecuado si hay poco volumen de información y clientes, pero no como norma habitual.

Saludos.
Responder Con Cita
  #17  
Antiguo 03-03-2004
Avatar de barman
barman barman is offline
Miembro
 
Registrado: may 2003
Posts: 139
Poder: 21
barman Va por buen camino
Guenas, veo a otro sufrido interlocutor con mi problema de eventos:

ya intenté utilizar post_events y creé el trigger asociado after update, e incluso en el componente hice un ibevents1.add("evento") e ibevents1.registerEvent (lo estoy recordando de memoria asi que disculpadme si no es fiel a la realidad el nombre del procedure) tal y como kinobi ya me recomendó en otro post.....pero nada....no hacia nada.....tenia el nivel de aisalmiento a read-commited, hacia comitretaining en el afterpost y nada...el trigger pasaba de mi..

ACTUALIZA LOS IBX
Responder Con Cita
  #18  
Antiguo 03-03-2004
Avatar de StartKill
StartKill StartKill is offline
Miembro
 
Registrado: ene 2004
Posts: 299
Poder: 21
StartKill Va por buen camino
Hola Barman, dale una mirada a esta, en algo ayudará

http://www.clubdelphi.com/foros/showthread.php?t=7269

Your friend

StartKill
Lima-Perú
Responder Con Cita
  #19  
Antiguo 04-03-2004
Avatar de barman
barman barman is offline
Miembro
 
Registrado: may 2003
Posts: 139
Poder: 21
barman Va por buen camino
StartKill my friend , he respondido al post al ver el tema de los eventos, yo tenia el sig problema, que ademas he planteado en este foro, estaba todo bien realizado, pero no hacia nada o daba una violacion de memoria, actualiza los componentes de acceso a interbase y se quitaron todos los problemas, no tuve ni que tocar el codigo que habia realizado, simplemente funciono.
Responder Con Cita
Respuesta


Herramientas Buscar en Tema
Buscar en Tema:

Búsqueda Avanzada
Desplegado

Normas de Publicación
no Puedes crear nuevos temas
no Puedes responder a temas
no Puedes adjuntar archivos
no Puedes editar tus mensajes

El código vB está habilitado
Las caritas están habilitado
Código [IMG] está habilitado
Código HTML está deshabilitado
Saltar a Foro


La franja horaria es GMT +2. Ahora son las 15:52:09.


Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Traducción al castellano por el equipo de moderadores del Club Delphi
Copyright 1996-2007 Club Delphi