Urgente insert update

El problema con el que te estás encontrando es un problema con el que, a día de hoy, sigo encontrándome yo a menudo. Es una putada, pero vamos a ver si lo solucionamos.
Cuando ejecutas sentencias de actualización SQL a través de la propia conexión (es decir, con el db.execute) pasas toda la gestión de errores al motor de la base de datos que estás pretendiendo actualizar y, por lo que no te salta el error, es porque determinados errores que se pueden generar en la base de datos no se pasan a la aplicación que los está generando. Vamos a ver, por ejemplo, cuando ejecutas una consulta de actualización en Access, por lo general (a no ser que configures el access de otra manera) se te pide confirmación para llevar a cabo la actualización (el típico mensaje de "se van a actualizar nosecuantas filas, no podrá deshacer este cambio, ¿desea continuar?") y, si te das cuenta, cuando llamas a este tipo de acciones desde una aplicación externa, nos saltamos este paso de confirmación.
¿Por qué sucede esto? Porque se está llamando al proceso de actualización desde dos "motores" distintos. ¿Qué está pasando cuando llamas al db.execute y no se lleva a cabo la actualización? Pues que el motor de la base de datos está generando uno de esos "errores" que no se pasan a la aplicación. (Creo que la explicación que te estoy dando no es del todo "correcta" pero es lo que siempre me he imaginado que ocurre cuando me he encontrado ante este tipo de situaciones)
Entonces, ¿qué es lo que puede estar pasando y cuales podrían ser las soluciones?
1º.- Lo más probable es que se esté dando algún error en la actualización (alguna infracción de clave, algún error en la conversión de tipos de algún campo, o la necesidad de rellenar algún campo que tienes a "NOT NULL" y que estás intentando actualizar a NULL) y que el motor no nos esté avisando.
2º.- Que se esté dando algún tipo de error en las opciones de actualización del propio registro, es decir, que tienes en las opciones de la apertura de la conexión, algún parámetro que no está bien configurado y que sólo te permite abrir Recordsets para lectura pero no te permite actualizar datos.
Soluciones a la primera opción:
Debes tener en cuenta el puto idioma, es decir, los "convencionalismos" de tu sistema operativo a la hora de escribir fechas, valores decimales, etcétera...
Access, a la hora de escribir un valor decimal, pinta en la pantalla una "coma" como separador decimal, pero el Transact SQL (que es el lenguaje que utiliza el método db.execute) utiliza un "punto". Si usas el método de ADO AddNew o simplemente el Update, no vas a tener que preocuparte demasiado por esos "convencionalismos", ADO directamente utilizará los que la base de datos necesita, pero si estás usando T_SQL, tienes que cambiar las "comas" por "puntos" para que realmente se pasen decimales (porque si pasas una "coma", T_SQL considerará que estás usando un divisor de campos, o un separador de criterios o cualquier otra cosa diferente a un separador de decimales, generará un error interno del que no te avisará, cancelará la actualización y tú te quedarás preguntando qué coño ha pasado)
En estos casos, a veces, es útil pasar los números entre comillas simples (como si fueran cadenas de texto) para que el propio T_SQL realice la conversión del tipo de datos de cadena al tipo de datos que tiene el campo de destino, pero esta opción no es demasiado recomendable porque no tienes ni idea durante el proceso, de qué tipo de conversión te está llevando a cabo (y no sabes ni el redondeo que practica ni el número de decimales que utiliza para hacerlo).
Con los campos de fecha pasa algo parecido. Tú pones una fecha y de repente ves que en la base de datos se ha introducido otra totalmente diferente...
En los dos casos yo suelo usar las funciones de REPLACE y FORMAT de Visual Basic para "formatear" los datos antes de pasárselos al método db.execute (sustituyendo las "comas" por "puntos" y dando formato a las fechas") pero esto tampoco es del todo correcto ya que estás obligando a la aplicación a realizar operaciones sobre algo que debería, desde el primer momento, estar bien "formateado".
Otro caso es el de las infracciones. Me imagino que tendrás siempre en mente cuales son las claves principales de la tabla que estás pretendiendo actualizar y cuales son los campos que no admiten valores nulos. De estos errores el método db.execute no suele avisar tampoco.
Ante la segunda posibilidad:
Si estás tratando de actualizar un Recordset que lleva cláusulas del estilo JOIN... ON o GROUP BY o WHERE (con varios campos), le estás pidiendo a Access que actualice algo que "no se puede actualizar" en principio. Para estos casos, lo único que se me ocurre es utilizar directamente los métodos AddNew y Update del Recordset abierto por ADO con las opciones de Dynamic y Optimistic que el noventa por ciento de las veces funciona pero implica más código y más tiempo de ejecución.
Por lo general, se pierde mucho tiempo tratando de averiguar porqué un db.execute no actualiza efectivamente la tabla. Por eso, yo, en cuanto me encuentro en una de estas situaciones, lo primero que hago es programarme la opción en ADO (abriendo el recordset y utilizando sus métodos) para ver cómo se comporta en este caso (además, ADO sí que avisa del error cuando se produce) y, si veo que el error es muy evidente y de fácil solución, es entonces cuando vuelvo a la opción de db.execute con las características que me ha impuesto ADO (el principal problema que te vas a encontrar en que con db.execute, no puedes determinar las opciones de bloqueo de registros, ni tipos de actualizaciones)
En definitiva, la única solución realmente efectiva para este tipo de problemas es el ensayo / error. Resumiendo, los principales puntos que debes tener en cuenta para actualizar pasando directamente a través del T_SQL son (por orden de probabilidad):
-Decimales en campos numéricos, conversión de fechas y demás problemas con campos que necesiten tipos especiales
-Restricciones de claves, principales o no en la tabla, así como campos requeridos e indexados
-Opciones del motor que se está ejectutando (es decir, elegir correctamente al abrir la conexión entre adUseClient o adUseServer) y opciones del tipo de bloqueo de registros y actualizaciones (incoherentes, snapshot, y dinámicas)
En cualquier caso, aunque te suponga el triple de código, te recomiendo la opción de tener siempre a mano el código de apertura y actualización del Recordset en ADO para corregir los errores del T_SQL.
Espero que esto te sirva para algo, en caso de que no.