Domanda

sto mantenendo un accesso multiutente 2000 DB collegato ad un database MSSQL2000, non scritto da me.

La progettazione del database è molto scarsa, quindi dovrete portare con me.

Nel modulo 'clienti' c'è un campo 'Customer_ID' che di default ha bisogno di ottenere il prossimo ID cliente a disposizione, ma l'utente ha la possibilità di sovrascrivere questa scelta con un ID cliente esistente.

Ora, il campo Customer_ID non è il PK della tabella Clienti. E ', inoltre, non unico.

Se un cliente chiama due volte per inviare un lavoro, la tabella avrà due dischi, ciascuno con le stesse informazioni dei clienti, e lo stesso ID cliente.

Se un utente crea un nuovo ticket, Accesso fa una ricerca rapida per il prossimo ID cliente a disposizione e la riempie. Ma non salva il record. Ovviamente un problema -. Due utenti la modifica deve tenere traccia del lavoro altrui in modo che non ingannano un ID cliente

Quindi voglio modificare il pulsante "Nuovo record" in modo da risparmiare il biglietto giusto dopo la creazione di uno nuovo.

Il problema è che, quando verifico il cambiamento, ottengo "Questo record è stato modificato da un altro utente dopo l'avvio modificarlo".

sicuramente non altri utenti DB. L' 'altro utente' stato presumibilmente la mia costretto Salva.

Tutte le idee?

È stato utile?

Soluzione

Date un'occhiata al vostro tavolo collegato in SQL Server 2000. Ha un campo che contiene il tipo di dati bit? L'accesso ti darà questo messaggio di errore in uno scenario tabella collegata se si dispone di un campo di bit che non ha un valore predefinito .

Potrebbe non essere quello che c'è che non va nel tuo caso, ma ho sperimentato lo stesso in un database di Access 2007 e rintracciato il problema ad un campo di bit senza alcun valore predefinito.

Altri suggerimenti

Ho visto questo comportamento prima e questo ha risolto il tutto per me:

tenta di aggiungere un campo timestamp alla tabella (basta aggiungere questo campo e aggiornare le tabelle collegate. Non è necessario compilare questo campo con qualsiasi tipo di dati).

L'errore che stai ricevendo solito accade quando:

  1. si modifica un record in un modulo e la forma è sporco (cioè, senza modifiche salvate),

E

  1. si esegue codice che utilizza DAO o ADO per eseguire SQL per aggiornare lo stesso record.

Per Jet, che sono due "utenti", in quanto si tratta di due diverse operazioni di modifica. La tabella sottostante è stato aggiornato dall'aggiornamento SQL, mentre i dati nel buffer di forma è ora obsoleto.

La soluzione più comune è quello di forzare un salvataggio prima di eseguire l'aggiornamento di SQL:

  If Me.Dirty Then
     Me.Dirty = False
  End If
  [run your SQL update here]

Ma se si sta utilizzando i moduli per modificare il record, si dovrebbe fare tutti gli aggiornamenti in forma, piuttosto che ricorrere a SQL per fare l'aggiornamento.

La situazione che lei descrive con la generazione la propria sequenza dovrebbe essere fatto in questo modo:

  1. utente preme NUOVO tasto RECORD.

  2. calc successivo valore di sequenza e memorizzarlo in una variabile.

  3. inserire un nuovo record con quel valore di sequenza tramite uno SQL INSERT.

4a. se il modulo è destinato a tutti i record nella tabella, rieseguire una query sotto forma di modifica dei dati (assumendo che il pulsante NUOVO RECORD è la forma in cui gli utenti modificano i dati), e utilizzare la navigazione segnalibro per passare al nuovo record con il valore sequenza che memorizzato nella variabile al punto 2.

4b. Se il modulo è non legato a tutti i record (come non dovrebbe essere se si tratta di una banca dati ben progettato), si sarebbe solo cambiare il record della maschera per caricare solo il nuovo record.

Un'altra alternativa è quella di evitare l'INSERT SQL e Requery (o il reset della recordsource) e semplicemente aggiungere un nuovo record nella forma esistente, impostare il campo sequenza per il nuovo valore e immediatamente salvare il record.

Il punto chiave è che per far funzionare tutto questo in un ambiente multi-utente, il record deve essere salvato non appena il valore della sequenza viene assegnato ad esso - non si può lasciare il record appeso là fuori non salvati, perché questo significa che il valore sequenza identica è a disposizione di altri utenti, che è solo per chiedere un disastro.

Questa è una vecchia questione, che ho incontrato da parte di Google, quindi mi presenterà la mia risposta.

Nel driver ODBC, assicurarsi di accendere delle versioni delle righe. Se la tabella è già in Access, dovrete farlo cadere e ri-collegamento alla tabella di origine.

Si dovrebbe essere in grado di dire se si dispone di versioni delle righe attivato perché Access dovrebbe aggiungere una colonna alla tabella denominata xmin.

Vorrei tenere traccia di se l'utente ha ignorato la nuova customer_id con un valore di loro. Se non hanno, allora la vostra applicazione dovrebbe essere in grado di verificare la presenza di un duplicato a destra prima di salvare e proprio auto-incremento di nuovo, e l'utente non ha dispiacerebbe prendere il default. Forse anche un po 'l'indicatore per l'utente che si doveva scegliere automaticamente un valore diverso.

:

Ho anche avuto lo stesso problema. Stavo cercando di aggiornare in una tabella utilizzando Spring MVC e ibernazione. Nel mio caso colonna versione della tabella contiene un valore superiore a 1 (cioè 3) tuttavia le informazioni di aggiornamento nella mia domanda dell'aggiornamento aveva valore di versione 1.

I nostri problemi era che il front end accesso stava cercando di salvare un int (sì / no) in un campo di bit mssql (0/1). Cambiare il database mssql a int campi funzionato come un fascino.

Ho appena mai incontrato un'altra situazione che genera questo errore. In una tabella mysql ho avuto due colonne di data che inizialmente aveva il valore di default '0000-00-00'. Più tardi è stato cambiato a NULL default, ma molte righe mantenuto il valore '0000-00-00'. Ho dovuto resettare manualmente i valori NULL per fermare l'errore.

Ci sono voluti un sacco di tempo per capire che cosa stava trigering l'errore, HTH qualcun altro.

Questo errore può anche essere gettato se la tabella di SQL Server contiene una colonna datetime2 (nel mio caso con il valore predefinito di sysdatetime ()). Cambiare il tipo di dati di nuovo a CURRENT_TIMESTAMP datetime predefinita arresta l'errore.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top