2016-08-24 9 views
2

Haben Sie gesucht und noch keine Lösung gefunden, die zu passen scheint. Vielleicht kann hier jemand ein paar Ideen anbieten.So lösen Sie Schreibkonflikt mit ungebundenem Zugriffsformular

Hintergrund

Anwendung in MS Access gebaut 2010 zu Access 2010 Datenbank verknüpften Tabellen verknüpfen kann schließlich.

Das Formular enthält einen Abschnitt 'Bearbeiten' (nicht gebunden) und einen Abschnitt 'Liste' (gebundenes Unterformular).

Viele Formen dieses Typs werden in der gesamten Anwendung verwendet.

Alle Formulare verwenden eine gemeinsame UpsertRecord()-Methode zum Einfügen/Aktualisieren von Datensätzen basierend auf ihren jeweiligen Feldern.

Ausgabe

Wenn die Schaltfläche ‚Speichern‘ klicken, wird der Schreibkonflikt Fehler angezeigt.

Schreibkonflikt

Dieser Datensatz von einem anderen Benutzer geändert wurde seit Beginn der Bearbeitung. Wenn Sie den Datensatz speichern, überschreiben Sie die Änderungen, die der andere Benutzer vorgenommen hat. Wenn Sie die Änderungen in die Zwischenablage kopieren, können Sie die Werte anzeigen, die der andere Benutzer eingegeben hat, und die Änderungen dann wieder einfügen, wenn Sie Änderungen vornehmen möchten.

Die Zeile, die den Fehler auslöst, ist, wo das Formular Recordsource auf eine SQL-Zeichenfolge festgelegt ist.

.RecordSource = strSQL 

Meine Interpretation

Obwohl die Form könnte direkt die untere subform Liste aktualisieren, ohne auf ‚Speichern‘ klicken, dann ist dies nicht wünschenswert Benutzer versehentlich Ändern von Daten zu vermeiden.

Also, ich versuche, das 'Speichern' durch das Click-Ereignis zu erzwingen, das wiederum die allgemeine öffentliche UpsertRecord() Methode zum Speichern der Daten aufruft. Diese Methode funktioniert einwandfrei, löst jedoch den Schreibkonflikt aus, da das Formular glaubt, dass es auch die Daten selbst ändert (ohne den Klick auf "Speichern").

Lösungen

Versuchte Ich habe m_SaveOK eine private Variable zu setzen versucht, spart mithilfe des Form_BeforeUpdate() Ereignis mit dem folgenden Code jedoch w/o die Schaltfläche Click-Ereignis zu verhindern, die auch die Schreibkonflikt auslöst.

Auch versucht, die Formulardaten zu speichern, bevor Sie die qry.SQL direkt speichern, aber auch dies ist fehlgeschlagen. Dieser Code war im Grunde eine Überprüfung auf schmutzig und zwingt ein Formular speichern mit frm.Dirty = False vor dem direkten Speichern.

If frm.Dirty Then 
    frm.Dirty = False 
End If 

Formular Bild

Dies ist, was die Form aussieht. Durch Klicken auf die Stift- (Bearbeiten-) Schaltfläche eines Datensatzes im Unterformular werden die oberen Steuerelemente aufgefüllt.

Wenn Sie auf die Schaltfläche "Speichern" klicken, wird der Datensatz in der Datenbank gespeichert und das Formular wird abgefragt, um die Teilformularliste zu aktualisieren.

Unbound edit form with bound subform list

Wie dem auch sei, ich würde ein paar Ideen schätzen, wie die Form, um zu verhindern versuchen, den Rekord im Vergleich zu den Save Schaltfläche Click-Ereignis zu speichern.

Vielen Dank im Voraus für Ihre Hilfe!

UPDATE

Subform Eigenschaften sind nicht Ergänzungen und Änderungen lassen (löschen ist in Ordnung, denn das ist, was die 'X'-Taste in der Liste enthalten ist), und keine Sperren gesetzt.

Nach Hinzufügen einiger debug.print Rechnung frm.Dirty und frm.subform.Form.Dirty Ich habe es verengt bis auf die Hauptform gegenüber dem Unterformular Dirty zu sein und den Konflikt verursacht.

Die zugrunde liegenden Tabellen werden ordnungsgemäß mit der Schaltfläche "Speichern" aktualisiert, das Formular bleibt jedoch Dirty. Also, obwohl ich derzeit nicht Write Conflict Fehler auslösen, verursacht der Dirty Zustand andere Fehler & unerwünschtes Verhalten auf Formular-Exit - You can't save this record at this time... und 2101 The setting you entered isn't valid for this property., wenn ich eine frm.Dirty = False nach der Schaltfläche ausgelöst speichern hinzufügen.

Also arbeite ich immer noch durch das Problem und würde mich über weitere Ideen freuen.

+2

Ich bin gerade überrascht, wenn die 'frm' auf' frm.Dirty = False' auf das Unterformular verwiesen wurde. Wenn nicht, dann versuchen Sie 'frm! [TheSubform] .FormDirty = False' – winghei

+0

Nein, eigentlich nicht. Sie schlagen also vor, dass das Unterformular beim Aktualisieren gegen das ungebundene Bearbeitungsformular verantwortlich ist. Ich muss mir das genauer ansehen. Vielen Dank! – NWdev

+0

Völlig unabhängig, aber verwenden Sie 'site && location' in Ihrem Label, um' Site & Location' in der Formularansicht zu erhalten. – Andre

Antwort

1

Für das Unterformular müssen die Eigenschaften Allow Additions, Allow Deletions, Allow Edits auf Nein und Record Locks auf No Locks eingestellt sein. Auf diese Weise sollte das Unterformular nicht mehr stören können.

+0

Danke @Tieme, gute Sache zu überprüfen. Überprüft das Unterformular und alle Werte außer "Löschungen zulassen" waren "Nein" oder "Keine Sperren". Während 'Erlauben Löschen 'übrig blieb, um zuzulassen, dass die Schaltfläche' Löschen '(x) einen Datensatz löschte, ging ich weiter und setzte dies auch auf' Nein 'im Unterformular und wiederholte die Schaltfläche' Speichern 'des Hauptformulars. Leider ergibt sich der gleiche 'Schreibkonflikt'-Fehler. – NWdev

Verwandte Themen