¿Hay algo equivalente al FlushBuffers en TADODataset?

[nachoasensio]

Hola:

Estoy creando una aplicación monopuesto con Turbo Delphi 2006 Explorer, Access y ADODataset. Todo funciona razonablemente bien, pero tengo un problema: antes de insertar un nuevo registro sobre un ADODataset, utilizo otro para obtener el valor máximo de un campo (select MAX(...)), de modo que sumo uno al número obtenido y uso ese resultado como valor para un nuevo campo. Con ese valor hago un insert sobre el primer dataset, lo asigno y hago un post. A veces, si hago dos inserciones muy seguidas (con un intervalo de 1 segundo o menos entre ellas) el número que obtengo es el anterior que obtuve, es decir, pese a que en los controles de datos (entre ellos un DBGrid) aparece la nueva fila con el nuevo código (y ya se ha hecho el post, dado que inserto, asigno y hago Post), éste no existe cuando el segundo ADODataset ejecuta la consulta que busca el máximo, por lo que devuelve el máximo anterior y se repite el código.

Antiguamente, con el BDE, existía un método llamado "FlushBuffers" que obligaba a Access a refrescar sus buffers y a asegurar que los datos guardados físicamente en la base de datos eran los correctos, pero este método ya no aparece con ADODataset.

Si espero 2 ó 3 segundos entre una inserción y la siguiente nunca tengo ese problema. Antes de poner un temporizador que bloquee la ejecución 3 segundos (solución "cutre" pero que funcionaría) me gustaría saber si alguien conoce la solución a este problema o el método que sustituye a FlushBuffers (si es que existe).

He probado a cerrar el primer dataset, ejecutar la consulta del segundo (la que calcula el máximo) y volver a abrir el primer dataset; también he probado a desactivarlo y activarlo (a ver si así refresca el buffer), pero no he logrado resolver el problema.

Muchas gracias por adelantado y perdonad si este problema ya se ha resuelto con anterioridad. He estado buscando por los foros y no lo he encontrado.

Saludos

Nacho

[luisgutierrezb]

la verdad no se que pueda estar pasando, a mi siempre me ha funcionado eso, sin embargo como sugerencia busca el folio exactamente antes de hacer el post y no en el insert, esto te sirve para cuando usen el programa 2 o mas usuarios

[nachoasensio]

Gracias, voy a probar a guardar en el programa el número y a controlarlo por software. Hay algo más de lo que me acabo de dar cuenta. Cuando trato de hacer un "AdoDataset.Delete" en alguna de las filas que repiten el número (esa columna no es un campo clave, ni es requerida ni pertenece a ningún índice o relación) obtengo el mensaje: "Información de columna de clave insuficiente o incorrecta; demasiadas filas afectadas por la actualización", y no me deja borrarla. Tengo que ir a Access para poder eliminarla.

Dado que es una aplicación para una administración pública, mi mujer opina que no me preocupe, porque dice que ningún funcionario teclea tan rápido...

Probaré a ver si así funciona, pero me sigue mosqueando que no refleje de forma instantánea los cambios. Lo único raro es que tengo el FreeReports montado sobre el primer Dataset... (a propósito, para quien use Turbo Delphi 2006 Explorer, que no permite añadir componentes ni viene con ninguno para informes, montar FreeReports en una aplicación es muy fácil - y gratis -; si alguien tiene interés os pongo un ejemplo de cómo hacerlo funcionar sin instalar los componentes...)

Saludos

Nacho

[Palmiro]

Hola...
Porque no usas como clave un campo autoincrementable. Porque a mi entender estas tratando de hacer lo mismo, pero de otra forma y mas complicada.

[nachoasensio]

Gracias por el consejo.

No puedo usar un campo autoincrementable porque, en access, producen "saltos" si, por ejemplo, insertas un registro y luego no confirmas la inserción. Necesito tener un control completo sobre el número, dado que es un identificador "oficial". De hecho, si se borra el registro con el número más alto, ese valor será el siguiente nuevo número, algo que no puede hacerse con los autoincrementados (al menos de forma directa).

Hace muchos años trabajé con Delphi 4 e interbase y éra mucho más sencillo, pero esta miniaplicación tiene que funcionar como interfaz de usuario para una base de datos access preexistente, lo que complica bastante las cosas...

Por ahora lo he resuelto con el timer (3 segundos), pero es una chapuza. Todos los intentos de cerrar datasets, refrescarlos (el Refresh no funciona con los ADO, no sé por qué), ir al primero y luego al último (para que lo recorra todo), buscar y asignar el valor justo antes del post del insert (como sugirió luisgutierrezb), ... no ha funcionado. Es como si el ADODataset necesitase, a veces, ese segundo para grabar físicamente en access, pese a que en el dbgrid y los dbedit aparece la información y el registro es relativamente pequeño, quedando esos registros en una situación extraña, dado que son idénticos entre sí (la tabla no tiene clave primaria ), por lo que luego el ADODataset no los puede eliminar...

Todo parece apuntar al viejo problema de los buffers de access, pero al no tener ya disponible el FlushBuffers...

Saludos

Nacho