He podido descubrir mas cosas.
Uno de los registro que graba supongamos que tiene la siguiente estructura
Numero, Blob, Blob, etc campos.

Pues hacia lo siguiente

Tabla.edit;
tabla[ 'Numero'] := tabla[ 'Numero'] + 1;
Tabla.Post;


Hace las inserciones en otros ficheros.
Realiza el commitretaining.

Pues he comentado la primera parte donde incrementa un contador, y no ha vuelto a pasar. Todo funciona ok. Resulta que los campos blob uno es una hoja excel y el otro un grafico bmp, que bien bien podrian ocupar esas 460 paginas * 4096 bytes.

El problema sigo diciendo que es un bug de interbase, (aunque de todas formas debo reconocer que la programacion no es correcta. Tambien decir que yo jamas lo hubiera hecho asi, pero mi antecesor lo dejo asi y yo solo modifico lo que no funciona)

Bug de interbase, da la sensacion de que crea un registro nuevo para cada Edit que se realiza. Despues de realizar 200 edits, la base de datos tiene un tamaño impresionante y cuando realmente se realizar un commit (cerramos la
base de datos) graba la ultima modificacion y todo lo demas es en blanco.

No se, que opinais?

Entonces, no hay nada que hablar... el crecimiento de la base de datos es el normal...

No quedamos que no habían updates... solo inserts?
¿a que te referís con "cada edit que se realiza"?

Tengo la sensación que no nos has contado realmente como funciona el proceso...

Me gustaría también que me expliques que queres decir con esto último, en otras palabras, porque por ahora me siento perdido...

Hasta luego.

;)

Tienes razon, me equivoque al dar toda la informacion. Resulta que hay una tabla con dos blob uno es un excel y el otro un grafico.

Se realiza un bucle donde lo que se hace es modificar un campo numerico de la tabla citada y a parte añadir 3 o 4 registros en otra tabla.

Al final del bucle se realiza el commitretaining.

Lo que no entiendo es el incremento. Ya que la tabla con el registro grande no se añade nada, unicamente se modifica.

¿Hay alguna explicacion para esto?

Firebird crea una nueva versión del registro cada vez que modificas. Supongo, porque ahora no lo tengo claro, que esta nueva versión está incluyendo nuevas versiones de los blob's también... pero hará falta revisar los manuales para ver si es cierto.

Sigo pensando que realizar un commit en lugar de un commit retaining tendrá un buen efecto. Después de esto yo reduciría el sweep interval de esa base a unas 20 o 30 transacciones, suponiendo que ahora si nos has dicho la forma real de uso de la base.

Otra solución, podría ser insertar los blobs en un registro que no sufra modificaciones, en una relación 1 a 1 con el registro que si las sufre.

Hasta luego.

;)