Bloqueos tan superOptimistas que no me bloquean :(

[jachguate]

Empezado por Halfo

Peró insisto que en este punto hay un problema. Según lo que creo haber entendido en "la cara oculta de C++" del señor Marteens
...
los componentes IBX

El libro "La cara oculta de C++", al menos el que yo leí... hacia referencia a los componentes de acceso via BDE, y no a IBX, por lo que la referencia no necesariamente es válida.

De hecho, el comportamiento puede cambiarse con la propiedad UpdateMode, introducida en la clase TDBDataSet (del BDE), de upWhereAll, a upWhereChanged o upWhereOnly.

En el caso de las IBX, según recuerdo, las sentencias SQL generadas automáticamente para actualizar los registros en un TIBUpdateSQL, en el caso de insert y update comprenden solamente la llave primaria.

En cualquier caso, podrias modificar el comportamiento por defecto sobreescribiendo estas sentencias para incluir cualquier campo que sea de tu interes (incluso todos).

Me parece poco probable que los componentes dejen pasar por alto el hecho de que no se actualizara ningún registro en la BD, pero no me considero experto en el tema ni dispongo actualmente del tiempo para probarlo por mi mismo. Por lo tanto, dejo la idea, espero que vos hagas pruebas y nos saques de una buena vez de la duda.

Hasta luego.

[guillotmarc]

Hola.

Puedes utilizar un ClientDataset para modificar los registros. Conectas tu IBQuery a un DatasetProvider y este a un ClientDataset. Cuando quieras hacer modificaciones las haces en el ClientDataset, y para pasar los cambios a la Base de Datos llamas al ApplyUpdates.

La ventaja es que puedes usar las opciones upWhereAll, upWhereChanged, upWhereKeyOnly que comentaba Juan Antonio (se configura en el DatasetProvider). Esto hace que se ejecute una instrucción distinta en función de la opción seleccionada, incluyendo solo la clave primaria en la sección Where, o bien la Clave primaria más los campos que se van a modificar y finalmente todos los campos.

NOTA: Te recomiendo utilizar upWhereChanged. Que solo te va a provocar un error si intentas modificar un campo que ya ha sido modificado por otro usuario.

Saludos.

[Halfo]

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...

[guillotmarc]

Hola.

Lamentablemente tu duda no te la puedo resolver. Simplemente es que estamos hablando de componentes BDE y IBX, y nunca he utilizado ninguno de ellos.

Solo he pretendido ayudarte, aconsejándote el uso de unos componentes que si conozco (los ClientDatasets).

NOTA: Utilizar un control optimista, me parece la forma más correcta de atacar una base de datos. Aunque como ya te he comentado, no puedo decirte que es lo que haces mal con IBX.

NOTA 2: El uso de Clientdatasets no tiene nada que ver con el modo CachedUpdates, aunque el concepto sea parecido.

Saludos.