Possibili problemi:
1 Modifiche simultanee
Un motivo potrebbe essere che il record in questione è stato aperto in una forma che stai modificando. Se modifichi il record a livello di codice durante la tua sessione di modifica e poi provi a chiudere il modulo (e quindi provi a salvare il record), access dice che il record è stato modificato da qualcun altro (ovviamente sei tu, ma Access non lo sa ).
Salva il modulo prima di modificare il record a livello di codice.
Nel modulo:
'This saves the form's current record
Me.Dirty = False
'Now, make changes to the record programmatically
2 Chiave primaria o timestamp mancanti
Assicurati che la tabella SQL-Server abbia una chiave primaria e una colonna timestamp.
La colonna timestamp consente ad Access di determinare se il record è stato modificato dall'ultima selezione. Access esegue questa operazione ispezionando tutti i campi, se non è disponibile un timestamp. Forse questo non funziona bene con voci null se non c'è una colonna timestamp (vedi Problema con 3 bit Null ).
Il timestamp in realtà memorizza un numero di versione di riga e non un'ora.
Non dimenticare di aggiornare il collegamento della tabella in Access dopo aver aggiunto una colonna timestamp, altrimenti Access non la vedrà. (Nota:l'Upsize guidato di Microsoft crea colonne timestamp durante la conversione delle tabelle di Access in tabelle SQL-Server.)
Problema di 3 bit nulli
Secondo @AlbertD.Kallal, questo potrebbe essere un problema di bit null descritto qui:KB280730
(ultimo snapshot su WayBackMachine, l'articolo originale è stato cancellato). Se stai utilizzando campi bit, imposta il loro valore predefinito su 0 e sostituisci tutti i NULL inseriti in precedenza con 0 . Di solito uso un BIT DEFAULT 0 NOT NULL per i campi booleani poiché corrisponde maggiormente all'idea di un booleano.
L'articolo della Knowledge Base dice di utilizzare un *.adp invece di un *.mdb; tuttavia, Microsoft ha interrotto il supporto per Access Data Projects (ADP) in Access 2013 .
