Solución:
Tuve el mismo problema y lo resolví comparando dbml con la estructura de db. Una propiedad no estaba configurada como anulable y eso estaba causando el problema.
Así que verifique sus propiedades dbml y anulables.
Cada vez que veo este error, significa que algo cambió en la base de datos entre el momento en que cargué el registro / objeto / lo que sea y cuando intenté guardarlo. Sin duda, fue porque mi unidad de trabajo era demasiado grande.
No sé la naturaleza exacta de su aplicación, pero supongo que está creando un contexto de datos, cargando un registro o una lista de registros, realizando algunas operaciones en él, consumiendo algo de tiempo y ciclos de procesador, y luego en el termine de intentar guardar los datos modificados en la base de datos. Tal vez incluso cargar una instancia de un registro / objeto y almacenarlo en una variable de clase por un tiempo, y luego al final de una carga de página o hilo o lo que sea tratando de guardar cualquier cosa que haya cambiado. El problema es que debido a que LINQ almacenó una copia de eso, esa es la copia que quiere actualizar. Si los datos subyacentes cambian mientras tanto, se enoja.
Pregúntese esto, ¿qué pasa si coloca una transacción de bloqueo en sus datos durante toda la vida útil de sus objetos? Di cualquier cosa que hayas cargado puede modificar, nadie más podrá tocarlo durante ese tiempo. Básicamente, esa es la suposición aquí. Por supuesto, LINQ es un poco más optimista al respecto, no tiene sentido bloquear la fila o la tabla si es posible que nunca actualice los datos, pero piensa en esos problemas. Pregúntese qué se interrumpiría o ralentizaría significativamente si pusiera bloqueos transaccionales estrictos en sus objetos, y eso probablemente le indicará el código ofensivo.
Mi solución a esto es mantener mi unidad de trabajo lo más pequeña posible. No cargue el objeto y lo use como su copia de trabajo y almacénelo nuevamente en la base de datos, todo en un contexto. En su lugar, cargue el objeto y extraiga la información que necesita en un solo paso, luego averigüe los cambios que necesita aplicar y luego cargue / actualice / guarde el objeto. Seguro que provoca más viajes de ida y vuelta a la base de datos, pero le da una mayor seguridad de que está trabajando con la última copia de datos. Seguirá siendo “el último en entrar, gana”, lo que significa que si alguien realizó una actualización mientras trabajaba con los datos, es posible que se pierda, pero eso siempre es un riesgo a menos que bloquee el registro con una transacción. Sin embargo, le da la flexibilidad de que si alguien más está modificando campos no relacionados en la misma fila, ambos pueden operar con esos datos juntos.
GetTable (). Attach (newEntity, originalEntity);
Si no está utilizando un campo de versión para actualizar, el método anterior parametriza nuevos detalles y entidades de detalles antiguos, si la entidad original se cambia en este punto, seguirá recibiendo el mismo error, esto depende de usted para asegurarse. Esto funciona a las mil maravillas, lo he probado.