Siento volver a insistir, pero no se si consigo hacerme entender y transmitir mi duda, ya que todo el mundo acaba contestandome algo que ya sabia y que NO resuelve mi duda.
Respecto las dos ultimas contestaciones de jachguate y guillotmarc:
He hecho referencia al libro "La cara oculta de C++" porque es la unica lectura minimamente extensa y completa que tengo respecto al desarrollo de aplicaciones orientadas a BBDD en entornos RAD de Borland, ya se que esta un poco anticuado, pero todas las demas lecturas realizadas al respecto (Firebird/interbase,IBX,...) son documentos mucho más concretos o demasido generales y raramente hacen referencia a una metodologia consistente para el desarrollo. Por lo que mi base de conocimiento es un viejo libro + pequeñas ideas extraidas de manuales,articulos y respuestas del foro (si alguien tiene una buena recomendación de lectura que no se calle). En el libro "la cara oculta" se describen las actualizaciones optimistas como aquellas en que a la hora de editar los registros no se bloquean, se permite la edición concurrente y los problemas los tendrán los que intenten actualizar en segundo lugar ya que no encontraran el registro que estaban editando. Esto entiendo cuando leo:
Las dos aplicaciones pueden realizar las asignaciones al buffer de registro sin ningún tipo de problemas. Recuerde que este buffer reside en el ordenador cliente. La primera de ellas en terminar puede enviar sin mayores dificultades la petición de actualización al servidor. Sin embargo, cuando la segunda intenta hacer lo mismo, descubre que el registro que había leído originalmente ha desaparecido, y en ese momento se aborta
la operación mediante una excepción.
Pero el libro esta hablando de una tabla de del BDE y por eso menciona la propiedad UpdateMode donde especificar la forma de localizar el registro al actualizar. El libro tambien detalla lo que hace el BDE en realidad que no es mas que realizar un update con el WHERE para localizar el registro incluyendo la pKey o lo cambiado o todos los campos.
Bueno como el BDE esta anticuado y es muy 'pesado' , para conectarse a Interbase/Firebird actualemente lo mejor es utilizar IBX (o otros componentes directos IBO,IBPlus,...) y segun tengo entendido los componentes TIBTable, TIBQuery , TIBUpdateSQL existen por compatibilidad con el pasado y se debe usar TIBDataSet o TIBSQL. Luego el TIBDataSet nos oferece la posibilidad de configurar a nuestro antojo como actualizar nuestro dataser con ModifySQL por lo que podemos poner la misma sentencia SQL que pone el UpdateMode en el caso del BDE. Hasta aquí todo muy bien pero.....
El UPDATE FALLA y los componentes no me avisan!!!!!
He monitorizado con TIBSQLMonitor lo que esta pasando en el post:
Se realiza un update + un select + un fetch del registro.
En caso que no haya problema (no han modificado el registro) todo ok.
pero si observo el caso en que debería fallar el update obserbo:
Se realiza un update + un select + un fetch del registro + un PEQUEÑISIMO
SEOFReached. que supongo es el mensaje que da al realizar el fetch y no encontrar datos ,(curioso que del update no diga nada pero bueno)
No se si veis donde quiero llegar, intento realizar lo que yo entiendo como un control optimista de la concurrencia pero no puedo ya que no encuentro la forma de que se me avise que esta fallando algo (solo estoy exponiendo el caso del update, con el delete tambien pasa lo mismo, por suerte el insert no tiene esta problematica
).
A) ¿El planteamiento del control optimista es erronio?
B) ¿La implementación con estos componentes IBX es erronia?
C) ¿Me estoy dejando algo, y por eso no me saltan los fallos?
D) Ninguna de las anteriores.
Guillotmarc, de momento no quiero complicar más el tema con CachedUpdates y ApplyUpdates, que si utilizaré para los datos con master/detail, etc...