Access - Tabla vinculada por ODBC

Hola.
Tengo creada una aplicacion con .NET que se conecta por ODBC a un servidor IBM mediante una tabla vinculada de ACCESS.

La aplicacion funciona correctamente y realiza modificaciones, inserciones y consultas a dicha tabla vinculada pero nunca un DELETE, cuando los registros son analizados por un operario desde el IBM se realiza la limpieza de los mismos por lo que yo ya no los visualizo en la tabla al abrirla
La problematica es que aleatoriamente se pierden registros que se han modificado antes de que el operario los analize(de unos 2000 casos se habran perdido unos 20-30 durante 3 meses), a la vez yo hago una insercion de los registros en otra base de datos de access(local) y en esta no se pierden ninguno.

-Que puede hacer a una tabla vinculada eliminar registros (sin un delete claro)?
-He observado que aunque yo haga inserciones o modificaciones la fecha y la hora de la base de datos vinculada no se actualiza en el explorador de archivos, solo al entrar y ver los registros se modifica, lo que si se modifica es el archivo temporal de dicha base de datos vinculada (*.laccdb)
-Tengo todas las funciones de Visual que operan con la tabla vinculada entre bloques de try.. catch y siempre cierro las conexiones con la tabla aunque haya habido un fallo ademas de hacer commit y rollback en las inserciones y modificaciones, guardo en un .txt un historico de todos los fallos de la aplicacion y aunque no se produzcan fallos se siguen perdiendo registros.
-La tabla vinculada tiene una primary key ya que he intentado dejarlas sin primary key pero me error desde visual al realizar un insert o update.

Un Saludo y muchas gracias!

Te planteo varias hipótesis
Los usuarios son grandes creadores de formas para borrar sin permiso una de ellas es modificando y cambiando ese dato por nada
o duplicándolo con otro, por ejemplo si modificas un dato y lo dejas en blanco es un forma de eliminarlo.
Deberías crear una bitácora por usuarios y registro que modifica así te das cuenta quien te borra los registros.
Desconexiones
Hablas de un servicio web y talvez estén modificando un dato y en ese momento se vaya la energìa electrica o el internet, es probable que ese dato se dañe.
Para evitar esto debes crear un temporal del dato a modificar que si se borre por desconexión no se pierda el original y que a la hora de darle guardar modifique el original.

Creo que el problema no esta en lo poco que utilizas del entorno Access, sino en la aplicación que maneja esa base (Net).

Una tabla vinculada (que permita lectura y escritura) hará con la tabla origen lo que 'le ordene y mande' la aplicación o el operador, la vinculación es una forma de acceder a esos datos, no una copia de los mismos.

Se desconoce el origen real de los datos (IBM es una marca comercial, si bien es cierto que tiene entornos especializados para gestionar datos, en una maquina IBM o cualquier otra puede correr cualquier soft compatible)

Si se ha detectado perdida de datos, se debería analizar si se corresponden con una franja determinada (por si influyen procesos internos) y si las fechas (es una marca que tiene una gran importancia a la hora de la gestión interna) se la trata con la delicadeza adecuada.

Es un gran error considerar que el .laccdb es un símil de un archivo temporal .... su aplicación real es llevar un control de los accesos a la tablas (al MDB o similar) para evitar colisiones y gestionar la compartición de recursos, se borra al abandonar el ultimo usuario y se vuelve a crear en cuanto se vuelva a acceder a ella.

Normalmente la llave primaria es una exigencia de una base de datos (sea MySQL, SQL Server, Oracle ...) es la forma de identificar como único a un registro concreto.

Si el entorno esta dividido entre el acceso a la maquina IBM (con su gestor de datos), una aplicación en Net y algo de Access (la base con tablas vinculadas), se debería aclara en que parte 'entra cada uno' para poder llegar a un diagnostico fiable y acudir al foro adecuado para encontrar la solución, en principio si de Access solo se utilizan las tablas (vinculadas o no), tiene todos los papeles para ser considerado 'inocente' del desaguisado.

Enrique dijo Es un gran error considerar que el .laccdb es un símil de un archivo temporal .... su aplicación real es llevar un control de los accesos a la tablas (al MDB o similar) para evitar colisiones y gestionar la compartición de recursos, se borra al abandonar el ultimo usuario y se vuelve a crear en cuanto se vuelva a acceder a ella.
¨Pues mí estimado enrique todos los días aprendemos cosas nuevas aca te dejo como se hace un temporal

En mi caso y queriendo optimizar unas operaciones que tenían que trabajar con más de 50000 registros pensé en sacar antes de empezar a trabajar con estas, los registros que iba a necesitar, dejando así en unos 5000 registros (sí, ya sé que es una barbaridad para Access). Al principio hice lo que ví normal, realizar una consulta Select e ir realizando una query insert por cada registro, lo cual hacía que el trabajo se demorara bastante para comenzar, dando sensación de aplicación pillada.

La consulta que os traigo es lo que iba buscando y conseguí encontrar, se trata de realizar una consulta de select y de creación de tabla en cuestión de segundos, muy pocos segundos, veamos:

“SELECT * Into Nueva_Tabla_Tutoriales FROM Tabla_Tutoriales WHERE convideo = 1”

En la consulta anterior, tenemos una Select en las que podemos seleccionar los campos (en mi caso he dicho que todos con *) y realizo un INTO y le indico el nombre Nueva_Tabla_Tutoriales donde crearé la tabla y volcaré los registros que saque de la tabla FROM Tabla_Tutoriales con la condición que tengo en el WHERE en este caso todos los registros que tengan el campo convideo = 1

Repasando, lo único que cambiamos de una consulta select, es que introducimos la sentencia INTO <NombreTabla> que será donde guardaremos la consulta realizada.

No olvidéis que si la tabla está creada, tendréis que eliminarla anteriormente, para ello podéis utilizar:

DROP TABLE Tabla_Tutoriales

Creditos al programador Carlos DK



Esa es una forma la otra es llevando ese dato a variables que este solo en memoría.
y a la hora de guardar se guarda de la variable a la base y listo.

Gracias por vuestras respuestas.
Por lo que veo hay varios factores que puedan hacer que un registro se elimine.
-Caida de la red, datos erroneos enviados desde la aplicacion (fechas, campos nulos...)

-Tengo creado una base de datos (no vinculada) identica a la vinculada y a la vez que inserto o modifico en la vinculada, inserto y modifico en la no vinculada, en este caso los datos no desaparecen, solo de la vinculada por lo que puedo recuperar los registros, pero entiendo que esto no es una solucion.
-En cuanto al archivo .laccdb quizas estaba equivocado yo pensado que hacia la funcion de archivo temporal, lo que si he observado es que el archivo se queda continuamente abierto por lo que significa que un usuario (bien sea mi aplicacion, o el servidor del cliente que en este caso es un AS-400)
-El servidor IBM es del cliente por lo que yo no tengo acceso a el, una solucion yo ya le propuse es crear un log para ver cuando y quien borran los registros, pero me da larga, y entiendo que access no tiene esa funcion.
-Entiendo tambien que dejar la tabla sin primary key no seria la solucion, por lo que deberia de centrarme en la aplicacion.
-Revisare la aplicacion por si las fechas que envio no son correctas o le envio algun dato nulo pero entiendo que si seria asi lo haria siempre ya que la operativa es la misma siempre.

Un Saludo y muchas gracias!

La verdad es que no he tenido la curiosidad de 'destripar' el contenido del fichero de bloqueo, en las antiguas MDB era un simple archivo de texto en el que el programa (Access) anotaba al usuario al conectarse y lo borraba a desconectarse y (por eso de ser el ultimo) al ultimo le correspondía borrarlo (así como al primero crearlo) si solo había un usuario anotado (y no la abría con la opción de exclusividad) le permitía la compactación (y modificaciones a niveles básicos de gestión y diseño).

Ello implica que los usuarios deberían tener permisos sobre la carpeta, pues en caso contrario o eran de solo lectura (mirones) o no se dejaba compactar (la consideraba abierta y en uso).

En fin, los borrados pueden ser generados por la aplicación vinculada o por los accesos directos a la base (mediante otras aplicaciones) y como a vinculada es 'una copia virtual' sincronizada con la base de datos, reflejara las modificaciones que en ella se produzcan (ser una copia virtual no la hace culpable).

En las nuevas versiones existe la opción de macros a nivel de tabla, quizás eso permitiera anotar cuando se produce una modificación a nivel de tabla (y quien la genera), pero para ello la base tendría que gestionarse con usuarios y permisos, dado que un acceso libre no informa de quien la esta utilizando, serviría para conocer si el trasteo indeseado lo genera Access o es externo a el (pero si la gestión se efectúa con un entorno Net, esa posibilidad esta en entredicho)

Hola Enrique, Gracias por tu respuesta.

"En fin, los borrados pueden ser generados por la aplicación vinculada o por los accesos directos a la base (mediante otras aplicaciones) y como a vinculada es 'una copia virtual' sincronizada con la base de datos, reflejara las modificaciones que en ella se produzcan (ser una copia virtual no la hace culpable)."

No entiendo realmente lo que quieres decir, al acceder la aplicacion creada en .NET y el servidor IBM a la copia virtual(*.laccdb) a la vez podria haber conflicto?
Lo que si he notado es que la base de datos no cambia la fecha de modificacion hasta que entras a ella por access y visualizas los registros (lo puedo entender ya que no tiene registros reales sino que muestra los del servidor IBM) pero si cambia la fecha del archivo *.laccdb en cada modificacion e insercion ademas de quedarse visible todo el rato por lo que entiendo que el ultimo usuario que la ha usado no la ha borrado?

Un Saludo y gracias!

Olvidate del fichero de control de accesos, si te fijas en el tamaño veras que como copia tiene una capacidad exigua, la misión de ese fichero es la asimilable a un portero que anota/borra a los que entran en la fabrica, cuando todos se marchan 'cierra la portería' y es un proceso autónomo, si nunca desaparece (aunque cambie su fecha) es porque alguien sale de forma inadecuada o la aplicación deja algo abierto.

Access genera para uso interno una copia de los datos a los que se accede y cuando se accede a ellos en forma efectiva 'refresca' sus valores (a eso llamo 'copia virtual') apreciaras que si compactas tiene un tamaño y cuando accedes a los datos (o generas 'trafico' con una consulta ....) el tamaño crece (eso es el espacio que utiliza como cache local) y que en una aplicación que este bien diseñada, suele ser bastante constante.

Muchas Gracias por tu respuesta Enrique.

No se puede explicar mejor, ahora lo comprendo perfectamente!

Un Saludo!