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.