for - Edición de problemas de registro en Access/SQL(Conflicto de escritura)

sql server import and export wizard access

Question

surgió un problema después de que una base de datos SQL que utilicé se migró a un nuevo servidor. Ahora cuando intenta editar un registro en Access (formulario o tabla), dice: WRITE CONFLICT: This record has been changed by another user since you started editing it...

¿Hay alguna razón no obvia para esto? No hay nadie más que use el servidor, he desactivado cualquier activador en la Tabla. Acabo de descubrir que tiene algo que ver con NULL, ya que los registros que no tienen ninguno están bien, pero algunas filas que tienen NULL no. ¿Podría ser con índices? Si es relevante, recientemente comencé a cargar en BULK a diario, en lugar de hacerlo uno a la vez usando INSERT INTO desde Access.

Answer 1

Encontré el problema debido al conflicto entre Jet / Access Boolean y los campos de bits de SQL Server.

Descrito aquí debajo de la trampa # 4 https://blogs.office.com/2012/02/17/five-common-pitfalls-when-upgrading-access-to-sql-server/

Escribí un script SQL para alterar todos los campos de bits a NOT NULL y proporcionar un valor predeterminado: cero en mi caso.

Simplemente ejecútelo en SQL Server Management Studio y pegue los resultados en una nueva ventana de consulta y ejecútelos: no vale la pena poner esto en un cursor y ejecutarlo.

SELECT
''UPDATE ['' + o.name + ''] SET ['' + c.name + ''] = ISNULL(['' + c.name + ''], 0);'' +
''ALTER TABLE ['' + o.name + ''] ALTER COLUMN ['' + c.name + ''] BIT NOT NULL;'' +
''ALTER TABLE ['' + o.name + ''] ADD CONSTRAINT [DF_'' + o.name + ''_'' + c.name + ''] DEFAULT ((0)) FOR ['' + c.name + '']''
FROM
sys.columns c
INNER JOIN sys.objects o
ON o.object_id = c.object_id
WHERE
c.system_type_id = 104
AND o.is_ms_shipped = 0;

Answer 2

Este es un error con Microsoft

Para evitar este problema, use uno de los siguientes métodos:

• Actualice el formulario que se basa en la vista de varias tablas En la primera aparición del mensaje de error que se menciona en la sección "Síntomas", debe hacer clic en Copiar al portapapeles o en Cambiar cambios en el cuadro de diálogo Conflicto de escritura. Para evitar la aparición repetida del mensaje de error que se menciona en los "Síntomas"
  sección, debe actualizar el conjunto de registros en el formulario antes de editar
  el mismo registro nuevamente. Notas Para actualizar el formulario en Access 2003 o en Access 2002, haga clic en Actualizar en el menú Registros. Para actualizar el formulario en Access 2007, haga clic en Actualizar todo en el grupo Registros en la pestaña Inicio.

• Utilice un formulario principal con un subformulario vinculado Para evitar la aparición repetida del mensaje de error que se menciona en la sección "Síntomas", puede usar un formulario principal con un
  subformulario vinculado para ingresar datos en las tablas relacionadas. Puedes entrar
  registros en ambas tablas desde una ubicación sin usar un formulario que se basa en la vista de varias tablas. Para crear un formulario principal con un subformulario vinculado, siga estos pasos:

  Cree un nuevo formulario basado en la tabla relacionada (secundaria) que se usa en la vista de varias tablas. Incluya los campos requeridos en el formulario. Guarde el formulario y luego cierre el formulario. Cree un nuevo formulario basado en la tabla principal que se utiliza en la vista de varias tablas. Incluya los campos requeridos en
  formar. En la ventana Base de datos, agregue el formulario que guardó en el paso 2 al formulario principal.

  Esto crea un subformulario. Establezca la propiedad Vincular campos secundarios y la propiedad Vincular campos maestros del subformulario al nombre del campo o campos que están
  utilizado para vincular las tablas.

Métodos del trabajo alrededor del soporte de Microsoft

Answer 3

Tuvo este problema, igual que el póster original. Incluso en editar directamente sin usar formulario. El problema está en los campos de bits, si su campo es nulo, convierte nulo en 0 cuando accede al registro, luego realiza cambios que esta vez es el segundo cambio. Entonces el 2 cambia de conflicto. Seguí la sugerencia de Olivier:

"Asegúrese de que la tabla tenga una clave principal y una columna de marca de tiempo ".

Y resolvió el problema.

Answer 4

Para superar este problema Creé VBA para cambiar otro campo en la misma fila. Así que creé un campo separado que agrega 1 a los contenidos cuando trato de cerrar el formulario. Esto resolvió el problema.

Answer 5

He visto una situación similar con MS Access 2003 (y anteriores) cuando estoy vinculado a MS SQL Sever 2000 (y anteriores). En mi caso, encontré que el problema eran los campos de bit en las tablas de la base de datos de MS SQL Server: los campos de bit no permiten valores nulos. Cuando agregue un registro a una tabla vinculada a través de MS Access 2003 la ventana de la base de datos, se devolverá un error a menos que establezca específicamente el campo de bit a True o False. Para remediarlo, cambié las tablas de datos de MS SQL Server para que cualquier campo de bit fuera predeterminado a valor 0 o 1. Una vez que lo hice, pude agregar / editar datos a la tabla vinculada a través de MS Access.

Answer 6

He tratado este problema con tablas de MS Access vinculadas a tablas MS SQL varias veces. La respuesta del afiche original fue extremadamente útil y de hecho fue la fuente de muchos de mis problemas.

También encontré este problema cuando accidentalmente agregué un campo de bit con un espacio en el nombre de campo ... sí ...

Había ejecutado alter table tablename add [fieldname] bit default 0. i La solución que encontré fue eliminar ese campo y no tener espacio en el nombre.

Answer 7

Tuve este problema y me di cuenta de que fue causado al agregar un nuevo campo de bit a una tabla existente. Eliminé el nuevo campo y todo volvió a funcionar bien.

Answer 8

Una razón podría ser que el registro en cuestión se haya abierto en una forma que está editando. Si cambia el registro de forma programática durante la sesión de edición y luego intenta cerrar el formulario (y, por lo tanto, intenta guardar el registro), el acceso indica que el registro ha sido modificado por otra persona.

Guarde el formulario antes de cambiar el registro mediante programación.
En la forma:

''This saves the form''s current record
Me.Dirty = False
''Now, make changes to the record programmatically

ACTUALIZACIÓN 1

Asegúrese de que la tabla de SQL-Server tenga una clave principal y una columna de marca de tiempo.

La columna de marca de tiempo ayuda a Access a determinar si el registro se ha editado desde la última vez que se seleccionó. Access hace esto inspeccionando todos los campos, si no hay marca de tiempo disponible. Tal vez esto no funcione bien con las entradas nulas si no hay una columna de marca de tiempo (ver mi ACTUALIZACIÓN 2).

La marca de tiempo realmente almacena un número de versión de fila y no un tiempo.

No olvide actualizar el enlace de la tabla en el acceso después de agregar una columna de marca de tiempo, de lo contrario, Access no lo verá. (Nota: el Asistente de Upsizing de Microsoft crea columnas de marca de tiempo al convertir tablas de acceso a tablas de SQL-Server).

ACTUALIZACIÓN 2

Según @ AlbertD.Kallal esto podría ser un problema de bits nulos que se describe aquí: KB280730 . Si está utilizando campos de bits, establezca su valor predeterminado en 0 y reemplace por 0 cualquier NULL ingresado anteriormente. Usualmente uso un BIT DEFAULT 0 NOT NULL para los campos booleanos, ya que se acerca más a la idea de un booleano.

El artículo de KB dice que use un * .adp en lugar de un * .mdb; sin embargo, Microsoft suspendió el soporte para Access Data Projects (ADP) en Access 2013 .

Answer 9

Estaba recibiendo el mismo mensaje de error. Id Column en la tabla de la base de datos se configuró en BigInt, al cambiarlo a Int se resolvió el problema.

Answer 10

He experimentado las dos causas detalladas anteriormente: cambiar datos directamente en una tabla que actualmente está vinculada a un formulario AND que tiene un campo de tipo ''bit'' en SQL Server que no tiene el valor predeterminado establecido en ''0'' (cero).

La única forma en que pude solucionar este problema es agregar el valor predeterminado de cero al campo de bits Y ejecutar una consulta de actualización para establecer todos los valores actuales en cero.

Para evitar el error anterior, tuve que ser inventivo. A veces puedo cambiar el orden de las declaraciones de VBA y mover Refrescar o Volver a buscar a una ubicación diferente, evitando así el mensaje de error. En la mayoría de los casos, sin embargo, lo que hago es DIM una variable de cadena en la subrutina donde llamo a la actualización directa de la tabla. ANTES de que llame a la actualización, configuro esta variable String al valor de Recordsource detrás del formulario enlazado, capturando así la declaración SQL exacta que se está utilizando en ese momento. Luego, configuré Recordsource del formulario en una cadena vacía ("") para desconectarlo de los datos. Luego, realizo la actualización de datos. Luego, configuré RecordSource del formulario de nuevo al valor guardado en la variable String, restableciendo el enlace y permitiéndole recoger los nuevos valores en la tabla. Si hay uno o más subformularios incluidos en este formulario, los campos "Enlace" deben manejarse de manera similar a Recordsource. Cuando Recordsource se establece en una cadena vacía, es posible que vea #Name en los campos ahora no vinculados. Lo que hago es simplemente establecer la propiedad Visible en False en el nivel más alto posible (sección Detalle, Subformulario, etc.) durante el tiempo en que Recordsource está vacía, ocultando los valores #Name del usuario. Establecer el Recordsource en una cadena vacía es mi solución cuando no se puede encontrar un cambio de codificación. Me pregunto, sin embargo, si faltan mis habilidades de diseño y hay una manera de evitar completamente el problema.

Un pensamiento final al abordar el mensaje de error: en lugar de llamar a una rutina para actualizar directamente los datos en la tabla de la tabla, encuentro una forma de actualizar los datos a través del formulario, agregando un control vinculado al formulario y actualizando los datos en para que los datos del formulario y los datos de la tabla no se desincronicen.

Answer 11

Si está utilizando tablas vinculadas, asegúrese de haberlas actualizado y vuelva a intentar antes de hacer cualquier otra cosa.

Pensé que los había actualizado pero no, resultó que alguien había actualizado la validación del formulario y las tablas SQL para permitir 150 caracteres, pero no había refrescado la tabla vinculada, por lo tanto, el acceso solo permitió ver 50 caracteres permitidos. Boom Write conflict

No estoy seguro de que este sea el error más apropiado para el escenario, pero bueno, la mayoría de los problemas interesantes nunca se marcan adecuadamente en ningún software de Microsoft.