La razón más común es que la cuenta de la huésped del Internet (IUSR_MACHINE), que es por abandono parte del “cada uno” grupo, no tiene permisos de escritura en el archivo de base de datos (.mdb). Para fijar este problema, utilizar la lengüeta de la seguridad en explorador para ajustar las características para que haya este archivo de modo que la cuenta de la huésped del Internet tenga los permisos correctos.
NOTA: Al usar las bases de datos de Microsoft Access con DIFICULTAD, es también necesario dar a la huésped del Internet que la cuenta permisos de escritura en el directorio que contiene el archivo de .mdb. Esto es porque el jet crea un archivo de .ldb para manejar la fijación de la base de datos. Usted puede también necesitar dar el permiso de lectura/grabación en la carpeta del “Temp” porque el jet puede crear ficheros temporales en este directorio.
Una segunda causa de este error es que la base de datos no fue abierta con el MODO correcto para la escritura. Si usted realiza el abierto en el objeto de conexión, usted utiliza la característica del modo para indicar los permisos en la conexión como se muestra aquí:
SQL = “sistema de productos de la ACTUALIZACIÓN UnitPrice = 2; ”
Fijar las conec = Server.CreateObject (“ADODB.Connection”)
Conn.Mode = 3 '3 = adModeReadWrite
Conn.Open “myDSN”
Conn.Execute (SQL)
Conn.Close
NOTA: Por abandono, el MODO se fija a 0 (adModeUnknown), que permite generalmente actualizaciones.
Otra causa de este error es que “solamente” el ajuste leído se puede llegar la página de las opciones para este DSN en el encargado de ODBC.
La edición y el trabajo pasados alrededor pertenece a cualquier fuente de datos del SQL. El error se puede causar por las declaraciones de SQL que violan la integridad de referencia de la base de datos. Aquí están algunas de las preguntas mas comunes que fallan:
Los grupos más simples a tratar de son ésos que usted no puede cambiar: crosstab, paso del SQL, unión, o preguntas de la acción de la actualización (o hacer-tabla) que tienen características de UniqueValue fijadas a sí.
Otra causa muy común es cuando el ensamblar incluye las tablas ligadas de ODBC que no tienen índices únicos. En este caso, no hay manera para que el SQL garantice que los expedientes son únicos en una tabla que tenga campos cuyo valor cambie con la pregunta.
Una causa tiene una solución alternativa robusta. Si usted intenta poner al día un campo del unido en el “un” lado de “uno-a-muchos” pregunta fallará a menos que usted dé vuelta a actualizaciones encendido de conexión en cascada. Esta manera, usted delega integridad de referencia al motor de JET.
