Linked-Zugang DB „Datensatz wurde von einem anderen Benutzer geändert“

StackOverflow https://stackoverflow.com/questions/973076

  •  13-09-2019
  •  | 
  •  

Frage

Ich bin die Aufrechterhaltung einer Multi-User-Access 2000 DB zu einer MSSQL2000 Datenbank verknüpft, nicht von mir geschrieben.

Das Datenbank-Design ist sehr schlecht, so dass Sie mit mir tragen werden.

Auf der ‚Kunden‘ Form gibt es ein ‚Customer_ID‘ Feld, dass standardmäßig benötigt die nächste verfügbare Kundennummer zu erhalten, aber der Benutzer hat die Möglichkeit, das Überschreiben diese Wahl mit einer bestehenden Kunden-ID.

Nun ist das Customer_ID Feld nicht der PK der Customer-Tabelle. Es ist auch nicht eindeutig.

Wenn ein Kunde zweimal ruft einen Job zu übergeben, wird die Tabelle zwei Datensätze erhalten, die jeweils mit den gleichen Kundeninformationen und der gleichen Kundennummer.

Wenn ein Benutzer ein neues Ticket erstellt, tut Access einer schnelle Suche nach der nächsten verfügbaren Kundennummer und füllt es in. Aber es nicht den Datensatz speichern. Offensichtlich ein Problem -. Zwei Benutzer der Bearbeitung der Arbeit Spur jeden anderen zu halten, so dass sie nicht über einen Kunden-ID übertölpeln bis

Also ich mag den „neuen Rekord“ Knopf ändern, so dass es das Ticket spart direkt nach dem Erstellen eines neuen.

Das Problem ist, wenn ich die Änderung zu testen, erhalte ich „Dieser Datensatz von einem anderen Benutzer geändert wurde seit Beginn der Bearbeitung“.

Auf jeden Fall keine anderen Benutzer auf der DB. Die ‚anderen Benutzer‘ wurde meine vermutlich gezwungen speichern.

Irgendwelche Ideen?

War es hilfreich?

Lösung

Werfen Sie einen Blick auf Ihre verknüpfte Tabelle in SQL Server 2000 Gibt es ein Feld haben die Bitdatentyp enthalten? Der Zugang wird Ihnen diese Fehlermeldung in einer verknüpften Tabelle Szenario, wenn Sie ein Bit-Feld haben, die keinen Standardwert hat .

Es kann nicht sein, was in Ihrem Fall falsch ist, aber ich habe das gleiche in einer Access 2007-Datenbank erfahren und verfolgen das Problem zu einem Bit-Feld ohne Standardwert.

Andere Tipps

Ich habe dieses Verhalten gesehen und das es für mich festgelegt:

Versuchen Sie, ein Timestamp-Feld zu der Tabelle hinzuzufügen (nur dieses Feld hinzufügen und Ihre verknüpften Tabellen aktualisieren. Sie müssen dieses Feld nicht mit jeder Art von Daten füllen).

Der Fehler Sie bekommen in der Regel geschieht, wenn:

  1. Sie bearbeiten einen Datensatz in einer Form und die Form ist schmutzig (das heißt, redigiert nicht gespeichert),

und

  1. Sie Code ausführen, die DAO oder ADO verwendet SQL ausführen denselben Datensatz zu aktualisieren.

Um Jet, ist, dass zwei „Benutzer“, weil es zwei verschiedene Bearbeitungsvorgänge. Die zugrunde liegende Tabelle wird von dem SQL-Update aktualisiert wurde, während die Daten im Puffer Form jetzt nicht mehr aktuell sind.

Die übliche Lösung ist, eine speichern zu erzwingen, bevor das SQL-Update ausgeführt wird: 

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

Aber wenn Sie Formulare verwenden den Datensatz zu bearbeiten, sollten Sie alle Updates in Form zu tun, anstatt zu SQL zurückzugreifen, das Update zu tun.

Die Situation, die Sie mit der Erzeugung Ihre eigene Sequenz beschreiben sollte auf diese Weise getan werden:

  1. Benutzer treffen NEW RECORD-Taste.

  2. calc nächsten Sequenzwert und speichern sie in einer Variablen.

  3. legt einen neuen Datensatz mit dieser Sequenz Wert über eine SQL INSERT.

4a. Wenn Ihr Formular auf alle Datensätze in der Tabelle gebunden ist, requery das Datenbearbeitungsformular (vorausgesetzt, die NEW RECORD-Taste auf dem Formular ist, wo Benutzer die Daten bearbeiten) und Lesezeichen Navigation verwenden, um auf den neuen Datensatz mit dem Sequenzwert zu bewegen, dass Sie in den variablen in Schritt 2 gespeichert.

4b. Wenn Ihre Form ist nicht gebunden alle Datensätze (wie es nicht sein sollte, wenn es sich um eine gut konzipierte Datenbank ist), würden Sie nur die Datenherkunft des Formulars nur ändern, um den neuen Datensatz zu laden.

Eine weitere Alternative ist das SQL-INSERT und requery (oder Zurücksetzen der Datenherkunft) und fügen Sie einfach einen neuen Rekord in der bestehenden Form zu vermeiden, setzen Sie das Sequenzfeld auf den neuen Wert und sofort den Datensatz speichern.

Der entscheidende Punkt ist, dass hierfür in einer Multi-User-Umgebung arbeiten, wird der Datensatz nur so schnell Wert gespeichert werden muss, wie die Folge zugeordnet wird - der Datensatz nicht verlassen kann, da draußen nicht gespeicherten hängen, denn das ist der gleiche Sequenz-Wert bedeutet, für andere Benutzer verfügbar ist, die für eine Katastrophe nur gefragt wird.

Dies ist eine alte Frage, die ich gegenüber Google gekommen bin, so werde ich meine Antwort einreichen.

In den ODBC-Treiber, stellen Sie sicher, dass auf der Zeilenversions einzuschalten. Wenn die Tabelle bereits in Access ist, werden Sie sie fallen lassen und eine Verknüpfung zu der Quelltabelle.

Es soll möglich sein, zu sagen, wenn Sie die Zeilenversionsverwaltung aktiviert haben, da Access eine Spalte zu Ihrer Tabelle namens xmin hinzufügen sollte.

Ich würde nachverfolgen, ob der Benutzer die neue customer_id mit einem Wert ihrer eigenen überschrieben hat. Wenn sie nicht haben, dann sollten Sie Ihre App der Lage sein, ein Duplikat zu überprüfen direkt vor dem Speichern und nur Selbstschritt wieder, und der Benutzer hat nichts dagegen, die Standard-Einnahme. Vielleicht sogar einiger Indikator für den Benutzer, die Sie automatisch einen anderen Wert wählen mußten.

Ich hatte auch gleiches Problem. Ich habe versucht, in einer Tabelle mit Spring MVC und überwinterte zu aktualisieren. In meinem Fall enthält die Version Spalte in der Tabelle einen Wert von mehr als 1 (d 3) jedoch die Update-Informationen in meiner Update-Abfrage hatten Versionswert 1.

Unsere Probleme waren, dass der Zugang vordere Ende einen int zu speichern versucht (ja / nein) in ein MSSQL-Bit (0/1) Feld. die MSSQL-Datenbank Ändern von Feldern in int arbeitete wie ein Charme.

Ich kam gerade quer durch eine andere Situation, die diesen Fehler erzeugt. In einer MySQL-Tabelle hatte ich zwei Datumsspalten, die ‚0000-00-00‘ anfänglich Standardwert hatten. Später wurde es geändert NULL auf Standard aber viele Zeilen gehalten, den Wert ‚0000-00-00‘. Ich musste manuell die Werte auf Null zurückgesetzt, den Fehler zu stoppen.

Es dauerte viel Zeit, um herauszufinden, was den Fehler wurde trigering, HTH jemand anderes.

Dieser Fehler kann auch, wenn die SQL Server-Tabelle eine datetime2 Spalte (in meinem Fall mit dem Standardwert von sysdatetime ()) enthält geworfen werden. Ändern des Datentyps zurück in Datetime Standard current_timestamp stoppt den Fehler.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top