¿Cómo "corto" una transacción pendiente?

[TiammatMX]

Buen día/tarde/noche (según aplique), jóvenes Delphineros...

Les platico que en casa tengo Firebird 2.1 conectado a mi aplicación mediante ADO (sí, yo sé que no es lo óptimo, pero así me lo requirieron) y sucedió algo que me alarma y me da un poco de desconfianza. Resulta que durante alguna de las múltiples pruebas a una pantalla que estoy desarrollando, mandé actualizar un campo que es vital para el funcionamiento del programa, de tipo VarChar(20); una vez que SE SUPONE que grabó el dato, me aparece una excepción en que se involucra a uno de los campos llave para recrear los datos en memoria (un Refresh, pues), corrijo el problema y vuelvo a probar...

Cuál va siendo mi sorpresa que NO ME PERMITE ACTUALIZAR EL CAMPO VARCHAR nuevamente, es más, utilizando un manejador de Firebird le intento actualizar el dato a mano e INVARIABLEMENTE se queda con el valor anterior a la actualización por más intentos (mediante Commit a la transacción) que le haga de modificarlo.

Preguntas, ¿será que debo recrear la tabla, cómo puedo evitar que ésto quede en el entorno real de trabajo para mi cliente? ¿Cómo puedo solucionarlo para continuar avanzando en la programación en lo que diseño una estrategia para que ésto no suceda?

Agradeciendo de antemano.

[Casimiro Notevi]

ummm... creo que no lo he entendido

[orodriguezca]

Por la descripción del problema se me ocurren dos teorías:

1. El campo Varchar(20) es un campo calculado y por tanto no se puede modificar.

2. Hay un trigger en la tabla que preserva el valor del campo varchar(20).

[TiammatMX]

Empezado por orodriguezca

Por la descripción del problema se me ocurren dos teorías:

1. El campo Varchar(20) es un campo calculado y por tanto no se puede modificar.

2. Hay un trigger en la tabla que preserva el valor del campo varchar(20).

Ninguno de ambas teorías..., es un campo varchar común y silvestre, en el que apenas estoy desarrollando la pantalla que lo modifica...

...pero suena interesante. Voy a revisar si Firebird no generó alguna especie de trigger automático.

[[birmain]]

Tuve una experiencia al principio de usar Firebird, durante un proceso de pruebas, donde me ocurrió esto, sin que nada aparentemente lo provocara (ni disparadores, ni campo calculado, ni nada) simplemente que el commit no funcionaba.

Resultó ser un problema de integridad de la base de datos que se resolvió con un backup y un posterior restore. No me ha vuelto a pasar, ahora tengo mas experiencia, soy más sistemático, y de todas formas Firebird es como una roca.

Mira eso por si acaso.

[TiammatMX]

Empezado por birmain

Tuve una experiencia al principio de usar Firebird, durante un proceso de pruebas, donde me ocurrió esto, sin que nada aparentemente lo provocara (ni disparadores, ni campo calculado, ni nada) simplemente que el commit no funcionaba.

Resultó ser un problema de integridad de la base de datos que se resolvió con un backup y un posterior restore. No me ha vuelto a pasar, ahora tengo mas experiencia, soy más sistemático, y de todas formas Firebird es como una roca.

Mira eso por si acaso.

Asunto solucionado..., condenada integridad referencial...

[Casimiro Notevi]

Empezado por tiammat

condenada integridad referencial...

bendita integridad referencial

[TiammatMX]

Empezado por Casimiro Notevi

bendita integridad referencial

Casi, para mí la integridad referencial es como intentar entender a una mujer, y te recuerdo que soy tres veces divorciado... jajajajajajaja

[Casimiro Notevi]

Empezado por tiammat

Casi, para mí la integridad referencial es como intentar entender a una mujer, y te recuerdo que soy tres veces divorciado... jajajajajajaja

Es que a la mujeres no hay que tratar de entenderlas, hay que aceptarlas como son