Hallo,
Ich habe ein Formular, welches wiederum 4 Unterformulare hat. Eines dieser Unterformulare hat genau die gleiche Tabelle (Zugriff über Abfragen, aber man landet beim gleichen Datensatz in der gleichen Tabelle) wie das übergeordnete Formular. (Habe ich nicht gebaut sondern, soll nur "schnell mal" ein paar Fehler beheben.)
In dem Hauptformular kann in einem Kombifeld ein Kunde aus einer Liste ausgewählt werden. Anschließend wird durch vba Code das Sub mit der gleichen Tabelle angepasst (Zahlungsbedingungen, RG Adresse, etc an den neu ausgewählten Kunden anpassen.)
Hierbei gibt es jedoch immer einen Schreibkonflikt weil "Ein anderer Benutzer" den Datensatz geändert habe. Das bin ich aber selbst. Niemand sonst ist auf der Datenbank.
Die DB im Hintergrund ist MS SQL.
Ich habe nun auch mit Werte durch docmd.runsql geändert und danach das Hauptform Me.requery probiert... Auch mit Me.dirty False... docmd.setwarnings false... Vor dem sql noch das formular speichern... Aber dieser Schreibkonflikt kommt jedes mal.
Hat jemand von euch noch eine Idee, wie ich diesen Konflikt umgehen kann? Oder Vielleicht auch nur automatisch "Eigenes verwerfen" kann, so schnell dass der User das kaum mitbekommt?
Hallo,
Du kannst es drehen und wenden wie Du willst, es kann auch immer nur eine Person aus einem Glas gleichzeitig trinken... (gäbe da noch ein paar andere zutreffende Beispiele ;-) )
Das Konzept mit den UFOs, die auf die selbe Tabelle (und selben Datensatz) zugreifen, ist nicht verwendbar..
Für welchen Zweck werden die (Unter-)Formulare denn in dieser Konstellation gebraucht?
Hallo!
Ein Me.Dirty = False auf die Hauptformulardatenquelle beim Wechsel in das Subform und im Subform ein Requery ausführen, um die neuen Daten zu erhalten, sollte helfen.
Beim Wechsel vom Subform ins Hauptform die gleiche (umgekehrte) Prozedur durchlaufen.
mfg
Josef
@Josef P.: Das hat leider auch nicht geholfen.
@DF6GL: Das Unterformular zeigt Kundendaten (Adresse, Zahlungsbedingungen, Ansprechpartner etc an). Da das in einem Auftrag ja auch nach x Jahren sich nicht ändert bloß weil im Nachhinein die RG Adresse geändert wird, wird redundant in die Auftragstabelle alles benötigte gespeichert. Aufbau ist Hauptform mit Auftragsdaten (Datum, Nr, Wer hat ihn angelegt etc...), Kopfdaten (Die gleiche Tabelle nur mit den Kundendaten halt), weiteres Unterformular für die Auftragspositionen (andere Tabelle mit Referenz zu dem Auftrag an den einzelnen Positionen), Unterformular mit Notizen und Dokumenten (auch in anderer Tabelle) weiteres Unterformular mit "Fussdaten" also zusätzliches, was im Bericht dann z.B. mit auf die Auftragsbestätigung kommt... Wieder in der Haupttabelle des Auftrages
Da ich den Mist nicht fabriziert habe wollte ich ungern an der grundlegenden Struktur des Programmes etwas ändern. Kann man vielleicht auch einfach statt, dass der Hinweis kommt und die Frage (ob Zwischenablage, eigene Änderungen verwerfen...) gestellt wird automatisch sagen dass man "eigene Änderungen verwerfen" wählt?
Hallo,
die Herumtrickserei ist keine dauerhafte Lösung.
Wenn ich die Beschreibung des Formular-Aufbaus richtig interpretiere, dann ist nur das UFO "Fussdaten" von dem Problem betroffen.
Wirf also dieses UFO heraus und füge ein Registersteuerelement mit zwei Seiten in das Hauptform ein.
Die erste Seite zeigt alle Steuerelemente, die schon jetzt im Hauptform sind, die zweite Seite erhält die Steuerelemente, die im UFO "Fussdaten" platziert waren.
Zur Ersatz-Fehlermeldung:
Möglicherweise(!) ist eine Msgbox mit passender Meldung beim Form-Ereignis "Bei Fehler" hilfreich.
2 Subforms Kopf und Fuss machen Probleme... Habe auch gerade entschieden diese umzubauen... Blöd nur, dass dieser Aufbau nicht nur in den Aufträgen so ist... Das gibts noch viel mehr mit gleichem Konstrukt...
Danke für die Antworten. ;)
:-\ Ich hatte eigentlich gehofft mir etwas Arbeit ersparen zu können...
Zitat von: Jennifer am August 22, 2019, 08:30:40
@Josef P.: Das hat leider auch nicht geholfen.
Der Ansatz von Josef sollte schon funktionieren. - Mit einer genaueren Problembeschreibung könnte man vielleicht erkennen, warum er das bei dir nicht tut.
Das Sub ist schon geladen während man im Haupt etwas ändert. Es bringt daher nichts beim Wechsel auf Sub Dirty False zu setzen. In dem Moment der Änderung im Hauptformular wird sofort, noch bevor man etwas machen könnte, die Fehlermeldung geworfen. Das KombiFeld ist noch nicht einmal wieder zu geklappt, wenn die Meldung kommt.
Zitat von: Jennifer am August 22, 2019, 10:03:26
Das Sub ist schon geladen während man im Haupt etwas ändert. Es bringt daher nichts beim Wechsel auf Sub Dirty False zu setzen. In dem Moment der Änderung im Hauptformular wird sofort, noch bevor man etwas machen könnte, die Fehlermeldung geworfen. Das KombiFeld ist noch nicht einmal wieder zu geklappt, wenn die Meldung kommt.
Kannst du probeweise mal das Sub-Form mit dem Verweise auf dieselbe Tabelle entfernen und dann schauen ob der Fehler immer noch auftritt?- Ich vermute: Ja.
PS: Dabei das Vorgehen exakt so wiederholen wie vorher!
Ich war jetzt schon beim Umbau. Zunächst Kopf und Fuss Unterformulare raus genommen aus dem Haupt. Registerkarten etc da gelassen. Fehler weg... muss jetzt halt nur noch den ganzen Kram auf die Register packen und alles was im Hintergrund per vba bei den UFOs gemacht wurde mit in das Haupt übertragen.
Hallo,
Haupt- und Unterformular auf die gleiche Tabelle ist zwar seltsam, aber keineswegs unmöglich. Access speichert einen geänderten Datensatz beim Wechsel zwischen HFO und UFO ohnehin immer automatisch, daher kann die Fehlermeldung gar nicht auftreten (nicht aus diesem Grund).
Wenn allerdings per VBA etwas an einem Datensatz geändert wird, ist das für das Formular das gleiche, als ob "ein anderer User" etwas gemacht hätte, hier ist dann vor Änderung durch VBA notwendig, die Änderungen im Formular zu speichern. Das betrifft aber auch nur VBA-Anweisungen, die direkte INSERT/UPDATE/DELETE-Anweisungen auf dem gleichen Datensatz (ggf. gleicher Page) durchführen. Ohne weiteres kann VBA natürlich an einem nicht gespeicherten Datensatz des Formulares Änderungen über dessen Recordset durchführen.
Da das Backend allerdings SQL Server ist und das Frontend vermutlich ACCDB/MDB, hast Du möglicherweise mit Datentypenkonflikten zwischen JET/ACE und SQL Server zu tun. Das betrifft hauptsächlich Fließkommazahlen. Um eine Änderung "durch einen anderen Benutzer" festzustellen, werden dabei alle Felder des Datensatzes im Frontend mit allen im SQL Server verglichen. Wenn dabei Rundungsfehler auftreten, kommt es zu dem Fehler. Daher sollte man grundsätzlich immer, wenn eine SQL Server Tabelle in Access verwendet wird, ein zusätzliches Feld mit dem Datentyp "timestamp" in das Tabellendesign aufnehmen, das von SQL Server selbst verwaltet wird. Dabei handelt es sich um einen datenbankweiten Zähler, der für jede Änderung einen neuen Wert in das Feld einträgt. Ist das Feld vorhanden, wird kein Feld-für-Feld-Vergleich mehr gemacht, sondern nur das alte Timestamp mit dem neuen verglichen, wobei es nie zu einem Datentypproblem kommt. Das Timestamp-Feld muß nicht in Abfragen eingebunden werden, einfach das Feld hinzufügen, den Rest erledigt SQL Server selbst.
Wie gesagt, nur notwendig in allen Tabellen, die direkt oder indirekt (über Abfragen) in Access-Formularen zur Datenänderung eingesetzt werden. Bei z.B. einer Lookup-Tabelle mit festen Status-Werten, die man im Frontend nicht ändern kann, wäre das also nicht notwendig.
Gruß
Christian
Ja SQL Backend und Accdb Frontend... Aber von Anfang an bei Umbau zu SQL (vorher alles lokal in Access) mit timestamp feld gearbeitet.
Hallo Jennifer,
ZitatIn dem Hauptformular kann in einem Kombifeld ein Kunde aus einer Liste ausgewählt werden.
Ist das Kombi vielleicht gebunden? Zum Navigieren verwendet man normal
ein ungebundenes Kombi.
gruss ekkehard
Hallo Beaker. Das Kombifeld selbst ist ungebunden. Ein weiteres verstecktes Feld ist gebunden. Das beinhaltet die Kundennummer und ist mit dem Kombifeld gekoppelt. Also wenn in der Liste etwas ausgewählt wird, wird der Wert in dem versteckten Feld gespeichert
Hallo,
ZitatAlso wenn in der Liste etwas ausgewählt wird, wird der Wert in dem versteckten Feld gespeichert
wozu soll das gespeichert werden ?
Wenn das versteckte Feld gebunden ist, änderst Du ja einen Datensatz mit jeder Auswahl aus dem Kombi.
Dient das ungebundene Kombi zum Suchen eines Kunden ?