Hola , gracias por responder.
Cita:
Empezado por pvizcay
mmm no, no se quedan pendientes, ya están en commit o completadas.. pero el punto es que la performance se degrada como dices..
|
exacto , aqui esta el problema y la gran cagada de firebird. la performance se degrada , y al final se corrompe , te lo aseguro.
[/quote]
Cita:
Empezado por pvizcay
para alarmas y eventos FB tiene los events.. la aplicación cliente que los "escucha" no tiene que crear una transacción para los mismos.. asi que esto es claramente falso
|
no me referia a los events de firebird , con esto me referia a que muestro una serie de registros que guardan alarmas y eventos de diversos tipos, tambien estados de distintos equipos hardware. todo ello con controles enlazados (dbgrid's , etc).
Cita:
Empezado por pvizcay
puedes hacer que las pantalla cargue los datos y luego cerrar la transacción.. (con controles no enlazados por ej); si es una operación interactiva no hace falta que quede un día la ventana abierta.. si te pones a pensar como solucionarlo encontraras 100 maneras elegantes de realizarlo..
|
Siempre he usado controles enlazados , creo que es una de las cosas en las que delphi se aventaja de sus adversarios. si por usar firebird , en algunos casos no voy a poder usar controles enlazados (que esten permanentemente mostrandose) , o voy a tener problemas por usarlos , creo que es un paso atrás y una desventaja en vez de una ventaja.
como bien dices , hay muchas formas de solucionar el problema , pero no habria nada que solucionar si firebird no tuviera dicho problema.
Cita:
Empezado por pvizcay
yo creo que si la diseñastes mal y estas enojado con firebird por eso.. es más gran parte del problema viene por los componentes de acceso a datos que usas que están pensados para programas con otros requerimientos.. si quieres algo mas tienes que escribir un poco de código.. diseñar una aplicación que corre 24x356 no es trivial, y ni siquiera hicistes una pequeña investigación de la tecnología que usastes.. yo creo que puedes aprender algo de todo esto que te sucedió.. éxitos!
|
No estoy enojado con firebird (solo conmigo mismo por haberlo elejido) , llevo usandolo en todas sus versiones , desde que se liberó ib6 , así que unas cuantas pruebas si que he hecho. lo que no sabia era que la bd se degradaba al mantener una transaccion activa (supongo que la mayoria de usuarios fb no lo saben) , ya que la > de aplicaciones no corren 24x365.
Escribiendo un poco de código todo puede hacerse , pero los controles gráficos enlazados están para que el programador pierda el menor tiempo posible en esto , dile a alguien que está acostumbrado a usar un dbgrid que para que firebird no se degrade , que use un stringgrid , o mejor aun que lo pinte directamente en el canvas.
Como ya he dicho , un sgbd que se degrada porque un cliente mantiene una transaccion activa , no me parece un sgbd serio. independientemente del tiempo que un cliente mantenga una transaccion abierta , fb deberia mantener el performance y la integridad de los datos , y no lo hace.
No hay que ser taliban de firebird (que nadie se ofenda) , para un tipo de aplicaciones firebird va muy bien (de hecho llevo usandolo y defendiendolo muchos años) , pero para otro tipo de aplicaciones , es mejor no usarlo (o se si usa , hay que tener en cuenta algunas cosas para que no se degrade).
Saludos