al hacer update la base de datos crece sin parar

[mensana]

Bueno ... más que "pendientes" son transacciones que han dejado registros que ya no son válidos pero por "lo que sea" no se han podido eliminar con un sweep

[tefots]

voy a probar con el performance monitor ese.
pero he revisado la aplicación , y no hay nada 'raro' , tan solo hago

try
query1.execsql
Query1.transaction.commitretaining;
Except
queyr1.transaction.rollbackretainig;
end;

y los querys son simplemente updates.
deberia hacer commit , en vez de commitretaining ?.
por eso no hace sweeep automaticamente ?.
la base de datos no tiene triggers ni procedimientos almacenados , simplemente tablas con sus primarykeys e indices.

he probado ha forzar hacerler un sweep , y nada , las transacciones siguen estando ahi pendientes .
el verdadero problema de todo esto , es que ademas de que la bd crece y crece , llega un momento que debe tener tantas transacciones por ahi perdidas que que la bd se espatarra , y el fbserver se pone al 100%.

saludos.

[mensana]

Empezado por tefots

... tan solo hago

Código Delphi [-]
try
 query1.execsql
 Query1.transaction.commitretaining; 
Except
 queyr1.transaction.rollbackretainig;
end;

deberia hacer commit , en vez de commitretaining ?.

commitretaining !! Ahí tienes el problema, haces un commit y retienes (continuas) la transacción. Debes hacer un commit/rollback normal

[tefots]

Empezado por mensana

commitretaining !! Ahí tienes el problema, haces un commit y retienes (continuas) la transacción. Debes hacer un commit/rollback normal

yo pensaba que commitretaining hacia lo mismo que el commit solo que finalizaba y retenia la misma transacción (evitando tener que abrir una nueva ) y que no afectaba negativamente a la base de datos.

Entonces el commitretaining /rollbackretaning no es bueno usarlo para ciertas cosas , sobre todo si se está usando la misma transaccion y realizando commitsretainings masivamente sobre esa transaccion.

gracias y un saludo

[mensana]

Básicamente el CommitRetaining sirve para una multi-transacción con varios "puntos de control" (checkpoint), pero siempre hay que finalizar con un commit normal.

En pseudo-código:

IniciarTransacción

try

Cambios en BBDD
CommitRetain (punto 1) // Los cambios son válidos en la BBDD

Cambios en BBDD
CommitRetain (punto 2) // Los cambios son válidos en la BBDD

... etc ...

Commit // Último commit

except
Rollback

[rastafarey]

Eso del CommitRetaining hay que usarlo con mucho cuidado ay que puede darte mas dolores de cabesas de lso que se iamginan.

Volviendo la tema del tamaño de la bd. Segun mencionastes haces muchas actualizaciones y pocas consultas segun veo es poco lo que sirves(los datos que se consultan) de ser asi pon un tamaño muy pequeño a la paginacion. de esta manera no se mantiene datos en memoria y la base de datos va ser mas pequeña con siderablemente.

La cosa es mas compleja que lo que te acabo de decir.

[Rolopy]

Buenas Tardes, un saludo desde Asunción del Paraguay....bueno navegando por elclubdelphi, encontre este hilo y me parecio interesante ya que en estos momentos estoy teniendo el mismo inconveniente, usando procedimientos almacenados en firebird 1.5 a la hora de hacer la llamada desde mi aplicativo ( delphi 7 + Zeos 6.62)....al procedimiento de actualización, la base de datos va incrementandose constantemente , cada vez que es llamado el procedimiento.

Se me ocurrio que algun garbage colector que use la base de datos no este eliminnando los residuos de datos o transacciones y por ello cada vez que se ejecuta el proc. crece mi base de datos.

No hay alguna forma de decirle explicita o implicitamente al motor para eliminar dichos residuos si asi fuese el caso?.

Desde ya muchas gracias por su atención.