¿Por qué CommitRetaining funciona después de agregar, pero no después de modificar?

[[Al González]]

¡Buen día a todos!

En una aplicación Delphi7 + IBX + Firebird 1.5, utilizo la operación CommitRetaining después de hacer una actualización de registro a una tabla.

Esto me permite que al guardar un registro nuevo, otras aplicaciones cliente tengan automáticamente acceso a él. Sin embargo, cuando modifico un registro que acaba de ser dado de alta, guardándolo de nuevo después de la modificación, CommitRetaining no actualiza dicho cambio.

En las demás aplicaciones cliente el registro se ve como fue guardado la primera vez. En la aplicación, al cerrar la tabla y volverla a abrir, veo que efectivamente el cambio no se realizó.

¿Podrían ayudarme con este extraño caso? Sospecho que tiene que ver con un impedimento de la base de datos para realizar la modificación física del registro. Sólo que no hay mensaje de error al respecto.

Gracias.

Al González .

[__cadetill]

Hola Al

Con que componente realizas las modificaciones? Con un TIBDataset? Si es así, mira que esté informada la propiedad ModifySQL (o algo así )

[[Al González]]

¡Buen día a todos!

Gracias por responder Cadetill.

Estoy utilizando TIBTable. Después de algunas pruebas adicionales, descubrí que funciona sólo si antes de modificar el registro, llamo al método Refresh de la tabla. Lo cual, claro está, no justifica el extraño comportamiento que se presenta.

Le hecharé un vistaso al código interno del método Refresh, para ver si encuentro otra pista.

De cualquier forma, les agradezco sus aportaciones.

Seguimos en contacto.

Al González .

[[Al González]]

¡Buen día a todos!

Bien, parece que ya encontré la causa del problema, no así todavía la solución.

Hice la misma prueba con un TIBDataSet y sudedió exactamente lo mismo. Luego utilicé un componente TIBSQLMonitor para examinar detenidamente las instrucciones SQL que se generaban cuando intentaba guardar el registro modificado.

Uno de los campos de la tabla es entero, autoincrementado con un generador y un disparador before insert en la base de datos. Cuando doy de alta un registro, dicho campo obtiene su valor correctamente en la tabla, más no así en la memoria del componente TIBTable/TIBDataSet. En este último, después de realizar el guardado (Post) del nuevo registro, el campo autoincrementado se presenta aún en blanco, con su valor nulo predeterminado (¿por qué? ¿debo refrescarlo? ¿cómo es adecuado hacerlo?). Por lo tanto, cuando intento guardar la modificación de un registro en la tabla, en ésta no hay físicamente un registro que coincida con ese valor nulo del campo en memoria, y la sentencia SQL Update interna no realiza ninguna modificación.

Ahora, con esto. Según veo, la solución está en hacer que el campo autoincrementado obtenga su valor correcto en la memoria del programa, antes de intentar hacer cualquier modificación sobre el registro. Si el disparador es before insert, entiendo que el campo debería presentar un valor, por lo menos después de guardar un nuevo registro (Insert Into).

¿Qué debo hacer para que ésto suceda? ForcedRefresh no surte efecto al respecto. Refresh si pero se cambia de registro, además de que tendría que llamarlo entonces siempre después de guardar un registro nuevo, por cada tabla de la base de datos que utilice un generador para alguno de sus campos.

Les agradezco mucho todas sus aportaciones.

Seguimos en contacto.

Al González .

[__cadetill]

Veamos, que no se si te he entendido. ¿Estás diciendo que en el Before Insert del TIbTable o TIbDataset coges el valor de la clave del nuevo registro? Si es así, es normal que no tenga ningún valor, en el Before Insert todabía no se ha añadido el registro. Lo que me extraña es que no te dé ningún error :s

Para asignar valores a los nuevos registros, yo te aconsejo utilizar el evento OnNewRecord

Pruebalo y nos comentas

[[Al González]]

¡Buen día a todos!

Hola Cadetill, agradezco mucho tus respuestas.

Con respecto a:

Empezado por cadetill

...en el Before Insert del TIbTable o TIbDataset coges el valor de la clave del nuevo registro?...te aconsejo utilizar el evento OnNewRecord...

Debo comentar que conozco y se cómo se utilizan los eventos BeforeInsert y OnNewRecord de TDataSet. Nada más que con "Before Insert", yo me refería al momento en el que un disparador (trigger) en la base de datos se ejecuta para asignar el valor al campo entero autoincrementado, utilizando un generador. Es decir un disparador creado con la sintaxis SQL Create Trigger Nombre For TABLA Before Insert As...

Empezado por Al González

...Uno de los campos de la tabla es entero, autoincrementado con un generador y un disparador before insert...Si el disparador es before insert, entiendo que el campo debería presentar un valor, por lo menos después de guardar un nuevo registro (Insert Into)...

El problema que tengo es que en pantalla (y en la memoria de TIBTable/TIBDataSet) no se presenta el valor del campo autoincrementado, aún cuando ya guardé el registro. Sólo se ve hasta que cierro y vuelvo a abrir la tabla.

Muchas gracias. Algo me dice que la solución está cerca.

Al González .

[StartKill]

Buenas a todos

Es muy interesante ver como las mentes del mundo tratan d solucionar errores, problemas, dudas que otras mentes, y eso que solo contamos con un "lenguaje escrito", sin tonos presisos de nuestro genio y humor.

Fue un "error" muy parecido que tratare de detallar

Tenia una tabla con la siguiente estructura
Tabla distritos
1.- FCOD_DPTO CHAR(03)
2.- FCOD_PROV CHAR(03)
3.- FCOD_DIST CHAR(03)
4.- FDES_DIST CHAR(20)
5.- FID INTEGER ---->campo autoincrementable con el triger before insert

*Los campos 1,2,3 son el campo Primary Key (...)
*El campo 4 el nombre del distrito
*El campo 5 es un campo autoincremetable con un disparador en este caso se dispara antes de insertar...

Bueno, utilice un componete IBQuery y un IBUpdateSQL que debo suponer que la union de estos hacen el mismo trabajo que el IBDataSet

Las propiedades de mantenimiento de esta tabla en el componente IBUpdateSQL estaban llenas de la siguiente forma:

DeleteSQL=delete from DISTRITOS where FID=:OLD_FID

InsertSQL=insert into DISTRITOS (FCOD_DPTO, FCOD_PROV, FCOD_DIST, FDES_DIST)
values (:FCOD_DPTO, :FCOD_PROV, :FCOD_DIST, :FDES_DIST)

ModySQL=update DISTRITOS
set
FCOD_DPTO=:FCOD_DPTO,
FCOD_PROV=:FCOD_PROV,
FCOD_DIST=:FCOD_DIST,
FDES_DIST=:FDES_DIST,
where
FID = :OLD_FID

RefreshSQL=select
FCOD_DPTO,
FCOD_PROV,
FCOD_DIST,
FDES_DIST,
FID
where
FID=:OLD_FID

Ojo: no se modica el campo FID en el servidor es el amo y señor de ese campo

Cuando añadia un registro me sucedia lo mismo que Comentan "En el cliente no veo el valor de campo incremementado, aun despues de hacerle su respectivo POST y CommitRe...", pues Amigo eso es correcto (eso creo), por que?, humm, el valor obtenido para el campo incremental se hizo en el servidor, el servidor se encargo de darle valor al FID sin que se enterara el cliente/insertador.

Si no hacemos ninguna operación el registro estará añadido en dicha tabla, pero si continuamos trabajando con el mismo registro que es lo que supongo que sucede, zasss, no borra, no refresca, no graba correctamente, por que?, facil si te fijas YO le escribí en el Delete/Refresh/ModySQL que el where es FID=:OLD_FID y cuando le lanzo el pedido al servidor para dicha fila no lo hace por no tener el FID en memoria... Pero como modifico el registro?, como obtengo el FID?, humm

Antes de hacer otra operacion es un refresh... a toda la tabla?..., pero solo quiero ese registro/Fila, nop, nop...

Cambié la intruccion del RefresSQL (la parte de where) asi:

RefreshSQL=select
FCOD_DPTO,
FCOD_PROV,
FCOD_DIST,
FDES_DIST,
FID
where
FCOD_DPTO=:FCOD_DPTO
FCOD_PROV=:FCOD_PROV
FCOD_DIST=:FCOD_DIST

Upps!!, el where es mi clave primary me funciono, refrescaba la fila y de esta forma tenia el FID de esta fila y ya podia hacer mi UPDATE Y DELETE sin problemas.

Espero que esta experiencia ayude en algo a todos aquellos que tienen problemas a estos, que son muy parecidos...

Your Friend

StartKill
Lima-Perú

[[Al González]]

¡Buen día a todos!

Hola Cadetill y StartKill.

Para los que venimos de bases de datos de escritorio, muchos de estos temas son realmente de coyontura conceptual, más que de fallas en las estructuras cliente/servidor. Sin embargo, sólo desmenuzándolos como lo hacemos ahora, es cómo realmente logramos cruzar el puente hacia las bases de datos grandes.

En efecto. Al guardar un nuevo registro, el disparador se ejecuta correctamente, otorgando un valor al campo autoincrementado y actualizando el respectivo generador. Pero el servidor no tiene la obligación de decirle a la aplicación cliente: "¡Hey! Este es el valor que le di al campo, atrápalo.", jeje .

Ahora, si en la aplicación cliente se deja el registro tal como acaba de ser guardado, el campo autoincrementado (en la memoria del cliente) seguirá sin valor alguno hasta que el conjunto de datos sea reabierto. Mientras tanto, se corre el riesgo de que ese campo con valor nulo sea utilizado como parámetro por alguna de las sentencias SQL del conjunto de datos, para las operaciones de actualizar, eliminar y refrescar, trayendo como consecuencia que dichas operaciones no se realicen o se ejecuten de forma incorrecta.

Descubrí que la clase TIBCustomDataSet (padre de TIBTable y TIBDataSet) tiene una propiedad llamada GeneratorField, objeto de clase TIBGeneratorField que sirve para que el conjunto de datos se encargue de incrementar uno de sus campos en memoria, utilizando uno de los generadores de la base de datos. Con ello, se consigue que el registro tenga un valor en el campo autoincrementado antes de ser guardado en el servidor.

La propiedad GeneratorField es publicada (pública y manipulable con el inspector de objetos) en la clase descendiente TIBDataSet, la cual, tengo entendido, es la adecuada para representar a una tabla. Sin embargo, aunque ya probé la misma propiedad con un TIBTable, curiosamente ésta clase no la hace publicada, ni siquiera pública (usé el truco de molde de tipo para poder acceder a ella).

El caso en el que estoy trabajando ahora (y que ya casi está listo), es una aplicación ADO-Access que estoy emigrando a IBX-Firebird. Cambiando las clases de todos sus componentes TADOXXX por los componentes TIBXXX que corresponde.

Aquí hago un paréntesis para mencionar la manera en que cambio la clase de decenas de componentes que ya están en varias formas y módulos de datos: Abro los archivos .dfm como texto, con el editor de código hago el reemplazo (Ctrl+R) de identificadores TADOTable por TIBTable, TADOQuery por TIBQuery, etc. De tal suerte que no hay necesidad de quitar cada componente ADO de la forma, agregar cada componente IBX sustituyo y volver a establecer todas las propiedades, campos persistentes, manejadores de eventos y enlaces que los primeros componentes tenían.

La razón por la cual utilicé (por ahora) componentes TIBTable y no TIBDataSet, es precisamente para facilitar esta migración ADO-Access a IBX-Firebird, ya que la aplicación original utiliza muchos componentes TADOTable. Convertir todos ellos a TIBDataSet sería más complicado que convertirlos a TIBTable, ya que ésta última clase tiene más propiedades en común con el componente ADO señalado. Posteriormente, se utilizará TIBDataSet en los nuevos módulos, y los actuales se irán convirtiendo a esta clase paulatinamente.

Por lo pronto es para mi muy importante tener un componente TIBTable que si publique la propiedad GeneratorField. Así que crearé una clase derivada de TIBTable para ese propósito, pero con algo adicional: Que este nuevo componente busque en la lista de generadores de la base de datos, aquel cuyo nombre se forme por el nombre de la tabla junto con el nombre de uno de sus campos, bajo el formato estándar Tabla_Campo_Gen, y que de encontrar uno realice automáticamente los establecimientos necesarios en la propiedad GeneratorField, evitando así que el programador final realice dichos establecimientos manualmente tabla por tabla. Esta útil característica, que será opcional con valor predeterminado de verdadero, posteriormente la extenderé también a una nueva clase derivada de TIBDataSet.

Aquí se pone a descubierto nuevamente la necesidad de que Object Pascal cuente con herencia insertada. Ya que, aunque pueda yo centralizar la mayor parte del código de la nueva característica, no dejará de existir algo de duplicidad de código en la nueva clase derivada de TIBTable con respecto a la nueva clase derivada de TIBDataSet (las dos clases primas tendrán algo de código idéntico). Con herencia insertada, sería posible crear una nueva clase derivada de TIBCustomDataSet, que incluyera la nueva característica, y hacer de esta clase el nuevo padre de TIBTable y TIBDataSet (inserción de nuevo padre en la jerarquía de clases), logrando que éstos dos componentes heredaran automáticamente dicha característica en la biblioteca de clases que empleo, evitando así duplicidad de código.

Muchas gracias por sus aportaciones al respecto. Seguimos en contacto.

Al González .