none
ACC 2007 Systemfehlermeldung

    Frage

  • Hallo zusammen,

    Proble: Datenquelle für ein Formular ist ein ADODB Recordset. Nachdem Daten im Formular geändert wurden, sollen diese mit einem DAO Recorset in die für das Formular zu Grunde liegende Tabelle geschreiben werden.

    Beim Wegschreiben des geänderten Datensatzes, erhalte ich eine vom System / von Access generierte Fehlermeldung. Sinngemäß:

    Der Datensatz wurde von einer dritten Person geändert ==> Dann stehen drei Buttons zur Verfügung: Datensatz speichern / Änderungverwerfen / In Zwischenablage kopieren.

    Da die Datensatzänderung gewünscht ist, sollte diese Fehlermeldung nicht erscheinten.

    Wie kann diese unterdrückt werden?

    Danke für die Unterstützung

     


    A_SqlDeveloper
    Donnerstag, 4. November 2010 11:57

Antworten

  • Hallo,

    A_SQLDeveloper wrote:

    Doch, das funktioniert sehr gut. ==> OK. Geht. Wenn ich jedoch das
    Formular an ein DAO.Recordset binde, einen Datensatz verändere und ihn
    dann wegschreiben will, erhalte ich wieder die Meldung eines
    Schreibkonfliktes, jedoch ohne die -Auswahlmöglichkeit des Speicherns

    Die Ursache fuer dein Problem ist, dass du mit 2 verschiedenen Methoden auf
    den gleichen DS zugreifst. Mit anderen Benutzern hat das nichts zu tun. Die
    Meldung liefert der Provider, nachdem er zwischen gelesenem und aktuellem
    Stand im BE Unterschiede festgestellt hat. Die Meldung laesst sich an der
    Oberflaeche nicht verhindern. Das gilt sowohl fuer ADODB als auch fuer
    DAO/ODBC.
    Du musst also den Zugriff anders gestalten. In Access laeuft es am besten,
    wenn der Datenzugriff Access ueberlassen wird, in Form von gebundenen
    Feldern/Formularen.

    Stehen die Oracle-Tabellen als verknuepfte Tabellen in Access zur
    Verfuegung? Falls nicht, erstelle die Verknuepfungen und arbeite darueber.

    Spendier dem Formular eine Abfrage als Datenherkunft (RecordSource) und filtere diese beim Oeffnen des Formulars:

    Private Sub Form_Open(Cancel As Integer)
      Me.Filter = "Feld1 = 123 AND ..."
      Me.FilterOn = True
    End Sub

    Vorteil: schnell(?), billig. Nachteil: der Benutzer kann den Filter entfernen/manipulieren, wenn das
    nicht explizit verhindert wird.

    Alternativ kannst du beim Oeffnen des Formulars die RecordSource selbst setzen:

    Private Sub Form_Open(Cancel As Integer)
      Me.RecordSource =  "SELECT Feld1, Feld2, ..." & _
       " FROM LinkedTable " & _
       " WHERE Feld1 = 123 AND ..."
    End Sub

    Vorteil: Benutzer kann Filter nicht entfernen.
    Nachteil: teuer, da erst beim Setzen der RecordSource der Ausfuehrungsplan
    erstellt wird.

    Ich möchte nur die Meldung über den Schreibkonflikt unterdrücken und
    einen geänderten Datensatz in die Tabelle zurückschreiben

    Daher verstehe ich die Frage nach dem Timestamp in der zu Grunde
    liegenden Datenbanktabelle nicht. Bei Bearbeitung der Tabelle wird die
    Tabelle gesperrt. Nur der aktuelle Benutzer hat auf die TAbelle / den
    Datensatz Zugriff. Die Idee das Datum der letzten Änderung abzufragen
    und zu prüfen, welcher später ist, sollte sich daher nicht stellen.

    Der Hinweis von Winfried bez. Timestamp betrifft den SQL Server als BE.
    Dort ist dieser fuer den reibungslosen Ablauf unverzichtbar, u.a. wird
    darueber die Version des DS vor dem Schreiben geprueft. Timestamp gehoert
    zu den Anforderungen, wird aber oft "vergessen", daher faellt der Hinweis
    immer wieder. Mit dem klassischen Timestamp (Datum/Uhrzeit) hat er
    uebrigens nichts zu tun. Weitere Details siehe
    http://msdn.microsoft.com/de-de/library/ms182776%28SQL.90%29.aspx

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    Freitag, 5. November 2010 10:15
    Moderator

Alle Antworten

  • Hallo!

    A_SQLDeveloper schrieb:

    Proble: Datenquelle für ein Formular ist ein ADODB Recordset. Nachdem Daten im Formular geändert wurden, sollen diese mit einem DAO Recorset in die für das Formular zu Grunde liegende Tabelle geschreiben werden.

    Ist das Formular an das ADODB-Recordset gebunden oder ist das ein
    ungebundenes Formular, deren Steuerelemente per Code befüllt werden?

    Beim Wegschreiben des geänderten Datensatzes, erhalte ich eine vom System / von Access generierte Fehlermeldung. Sinngemäß:

    Der Datensatz wurde von einer dritten Person geändert ==> Dann stehen drei Buttons zur Verfügung: Datensatz speichern / Änderungverwerfen / In Zwischenablage kopieren.

    Falls das ADODB-Rs auch an diese Datenquelle gebunden ist, könnte das
    bereits zur Änderung in der Tabelle geführt haben.
    Wann wurde das DAO-Recordset geöffnet? Eventuell hilft ein Requery vor
    dem Ändern der Daten im Recordset.

    Interessehalber nachgefragt: warum nutzt du für die Formular-Daten ein
    ADODB-Recordset und zum Speichern ein DAO-Recordset?
    Mir kommt das etwas umständlich vor.

    mfg
    Josef

    Donnerstag, 4. November 2010 12:13
  • Hallo!

    Das Formular ist an das ADO.Rexordset gebunden.

    Datensätze werden über das DAO.Recordset modifiziert. D.h. wenn alle madatory Felder auf Korrektheit geprüft wurden, wird das DAO.Recordset geöffnet und der Datensatz soll weggeschrieben werden.

    In Access 97 / 2000 war es m.E. möglich vom System erzeugte Meldungen generell zu unterdrücken. Geht das auch in Access 2007?

     

    Antwort auf Interessensfrage: Ich habe DAO vor Jahren benutzt und es ist mir geläufig. In ADO habe ich nur sehr geringe Erfahrung.

    mfg


    A_SqlDeveloper
    Donnerstag, 4. November 2010 12:24
  • Hallo!

    A_SQLDeveloper schrieb:

    Das Formular ist an das ADO.Rexordset gebunden.

    Verstehe ich dich richtig: du bindest ein Formular an ein ADODB-Rs,
    das die gleiche Tabelle nutzt, deren Datensätze später per DAO-Rs
    aktualisiert werden sollen?
    Warum speicherst du dann nicht gleich mit dem ADODB-Rs oder verwendest
    statt dem ADODB-Rs ein DAO-Rs bzw. stellst überhaupt nur die
    SQL-Anweisung in der Eigenschaft RecordSource ein?

    Datensätze werden über das DAO.Recordset modifiziert. D.h. wenn alle madatory Felder auf Korrektheit geprüft wurden, wird das DAO.Recordset geöffnet und der Datensatz soll weggeschrieben werden.

    In Access 97 / 2000 war es m.E. möglich vom System erzeugte Meldungen generell zu unterdrücken. Geht das auch in Access 2007?

    Du meinst vermutlich DoCmd.SetWarnings. Ob man damit die
    Schreibkonflikt-Meldung unterdrücken kann, weiß ich allerdings nicht.

    Wäre es nicht besser, das Problem zu beseitigen, statt die
    Problemanzeige zu unterdrücken?

    mfg
    Josef

    Donnerstag, 4. November 2010 12:45
  • Am 04.11.2010 schrieb A_SQLDeveloper:

    Proble: Datenquelle für ein Formular ist ein ADODB Recordset. Nachdem Daten im Formular geändert wurden, sollen diese mit einem DAO Recorset in die für das Formular zu Grunde liegende Tabelle geschreiben werden.

    Ich persönlich würde auch den Mischmasch verzichten und eine der
    beiden Varianten einsetzen. Dann aber konsequent.

    Beim Wegschreiben des geänderten Datensatzes, erhalte ich eine vom System / von Access generierte Fehlermeldung. Sinngemäß:

    Der Datensatz wurde von einer dritten Person geändert ==> Dann stehen drei Buttons zur Verfügung: Datensatz speichern / Änderungverwerfen / In Zwischenablage kopieren.

    Ist das Backend ein SQL-Server? Wenn ja, ist die Source eine View?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 4. November 2010 13:07
  • Verstehe ich dich richtig: du bindest ein Formular an ein ADODB-Rs, das die gleiche Tabelle nutzt, deren Datensätze später per DAO-Rs aktualisiert werden sollen? ==>Korrekt Warum speicherst du dann nicht gleich mit dem ADODB-Rs oder verwendest statt dem ADODB-Rs ein DAO-Rs bzw. stellst überhaupt nur die SQL-Anweisung in der Eigenschaft RecordSource ein? ==> a) So weit ich weiß, lassen sich die Formulare in Acc 2007 nicht an ein DAO.Recordset binden b) Beim Laden wird ein Modul aufgerufen, das gefilterte Daten liefert. Danach wird das Formular an dieses ADO.Recordset gebunden Ist das Backend ein SQL-Server? Wenn ja, ist die Source eine View? ==> Datenbank ist eine Oracle. Es wird keine View benutzt mfg
    A_SqlDeveloper
    Donnerstag, 4. November 2010 13:29
  • Am 04.11.2010 schrieb A_SQLDeveloper:

    Warum speicherst du dann nicht gleich mit dem ADODB-Rs oder verwendest statt dem ADODB-Rs ein DAO-Rs bzw. stellst überhaupt nur die SQL-Anweisung in der Eigenschaft RecordSource ein?
    ==> a) So weit ich weiß, lassen sich die Formulare in Acc 2007 nicht an ein DAO.Recordset binden

    Doch, das funktioniert sehr gut.

    b) Beim Laden wird ein Modul aufgerufen, das gefilterte Daten liefert. Danach wird das Formular an dieses ADO.Recordset gebunden

    Du kannst auch mit DAO filtern.

    Ist das Backend ein SQL-Server? Wenn ja, ist die Source eine View? ==> Datenbank ist eine Oracle. Es wird keine View benutzt

    Hat die Tabelle ein Timestamp Feld?

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 4. November 2010 13:47
  • Doch, das funktioniert sehr gut. ==> OK. Geht. Wenn ich jedoch das Formular an ein DAO.Recordset binde, einen Datensatz verändere und ihn dann wegschreiben will, erhalte ich wieder die Meldung eines Schreibkonfliktes, jedoch ohne die -Auswahlmöglichkeit des Speicherns

     

    Ich möchte nur die Meldung über den Schreibkonflikt unterdrücken und einen geänderten Datensatz in die Tabelle zurückschreiben

    Daher verstehe ich die Frage nach dem Timestamp in der zu Grunde liegenden Datenbanktabelle nicht. Bei Bearbeitung der Tabelle wird die Tabelle gesperrt. Nur der aktuelle Benutzer hat auf die TAbelle / den Datensatz Zugriff. Die Idee das Datum der letzten Änderung abzufragen und zu prüfen, welcher später ist, sollte sich daher nicht stellen.

    mfg


    A_SqlDeveloper
    Donnerstag, 4. November 2010 14:32
  • Am 04.11.2010 schrieb A_SQLDeveloper:

    Doch, das funktioniert sehr gut. ==> OK. Geht. Wenn ich jedoch das Formular an ein DAO.Recordset binde, einen Datensatz verändere und ihn dann wegschreiben will, erhalte ich wieder die Meldung eines Schreibkonfliktes, jedoch ohne die -Auswahlmöglichkeit des Speicherns

    Das glaub ich nicht. Wie sieht die Tabelle aus? Hast Du die Tabelle in
    A2007 verknüpft? Wenn ja, siehst Du in der verknüpften Access Ansicht
    ein Feld als Primary Key? Kannst Du die Entwurfsansicht von Access als
    Screenshot uploaden und den Link hier posten?
    http://www.file-upload.net/ Hast Du Code zum speichern verwendet? Gibt
    es Boolean Felder in der Tabelle? Wenn ja, werden die korrekt in
    Access verknüpft und dargestellt? Gibts NULL Werte in den Boolean
    Feldern?

    Ich möchte nur die Meldung über den Schreibkonflikt unterdrücken und einen geänderten Datensatz in die Tabelle zurückschreiben

    Nein, Du möchtest nicht die Meldung unterdrücken, sondern das
    speichern sauber implementieren.

    Daher verstehe ich die Frage nach dem Timestamp in der zu Grunde liegenden Datenbanktabelle nicht. Bei Bearbeitung der Tabelle wird die Tabelle gesperrt.

    Ein Timepstampfeld muß in jede Tabelle eingebaut werden. Zumindest
    beim Ms-SQL-Server soll das so sein. Insbesonders wenn über Access per
    ODBC zugegriffen wird.

    Nur der aktuelle Benutzer hat auf die TAbelle / den Datensatz Zugriff. Die Idee das Datum der letzten Änderung abzufragen und zu prüfen, welcher später ist, sollte sich daher nicht stellen.

    Der sog. Timestampt hat nichts mit der letzten Änderung zu tun, wie Du
    es jetzt glaubst.

    B2.3. Schreibkonflikt bei verknüpften Tabellen
    B2.1. Daten in verknüpften Tabellen nicht änderbar
    http://www.berndjungbluth.de/sqlfaq/faqb2.htm#B2.3.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Donnerstag, 4. November 2010 14:51
  • Hallo!

    ich denke wir sollten die Diskussion hier abbechen. Ich bin der Meinung, das bestehende Problem ausführlich beschrieben zu haben.

    Anstatt immer neu aufgeworfene Fragen zu beantworten, was ich nicht als unbedingt zielführend betrachte, ist mein Problem dennnoch nicht gelöst.

    Ich bedanke mich jedoch für die angebotenen Ansätze

     

    mfg


    A_SqlDeveloper
    Freitag, 5. November 2010 08:19
  • Hallo,

    A_SQLDeveloper wrote:

    Doch, das funktioniert sehr gut. ==> OK. Geht. Wenn ich jedoch das
    Formular an ein DAO.Recordset binde, einen Datensatz verändere und ihn
    dann wegschreiben will, erhalte ich wieder die Meldung eines
    Schreibkonfliktes, jedoch ohne die -Auswahlmöglichkeit des Speicherns

    Die Ursache fuer dein Problem ist, dass du mit 2 verschiedenen Methoden auf
    den gleichen DS zugreifst. Mit anderen Benutzern hat das nichts zu tun. Die
    Meldung liefert der Provider, nachdem er zwischen gelesenem und aktuellem
    Stand im BE Unterschiede festgestellt hat. Die Meldung laesst sich an der
    Oberflaeche nicht verhindern. Das gilt sowohl fuer ADODB als auch fuer
    DAO/ODBC.
    Du musst also den Zugriff anders gestalten. In Access laeuft es am besten,
    wenn der Datenzugriff Access ueberlassen wird, in Form von gebundenen
    Feldern/Formularen.

    Stehen die Oracle-Tabellen als verknuepfte Tabellen in Access zur
    Verfuegung? Falls nicht, erstelle die Verknuepfungen und arbeite darueber.

    Spendier dem Formular eine Abfrage als Datenherkunft (RecordSource) und filtere diese beim Oeffnen des Formulars:

    Private Sub Form_Open(Cancel As Integer)
      Me.Filter = "Feld1 = 123 AND ..."
      Me.FilterOn = True
    End Sub

    Vorteil: schnell(?), billig. Nachteil: der Benutzer kann den Filter entfernen/manipulieren, wenn das
    nicht explizit verhindert wird.

    Alternativ kannst du beim Oeffnen des Formulars die RecordSource selbst setzen:

    Private Sub Form_Open(Cancel As Integer)
      Me.RecordSource =  "SELECT Feld1, Feld2, ..." & _
       " FROM LinkedTable " & _
       " WHERE Feld1 = 123 AND ..."
    End Sub

    Vorteil: Benutzer kann Filter nicht entfernen.
    Nachteil: teuer, da erst beim Setzen der RecordSource der Ausfuehrungsplan
    erstellt wird.

    Ich möchte nur die Meldung über den Schreibkonflikt unterdrücken und
    einen geänderten Datensatz in die Tabelle zurückschreiben

    Daher verstehe ich die Frage nach dem Timestamp in der zu Grunde
    liegenden Datenbanktabelle nicht. Bei Bearbeitung der Tabelle wird die
    Tabelle gesperrt. Nur der aktuelle Benutzer hat auf die TAbelle / den
    Datensatz Zugriff. Die Idee das Datum der letzten Änderung abzufragen
    und zu prüfen, welcher später ist, sollte sich daher nicht stellen.

    Der Hinweis von Winfried bez. Timestamp betrifft den SQL Server als BE.
    Dort ist dieser fuer den reibungslosen Ablauf unverzichtbar, u.a. wird
    darueber die Version des DS vor dem Schreiben geprueft. Timestamp gehoert
    zu den Anforderungen, wird aber oft "vergessen", daher faellt der Hinweis
    immer wieder. Mit dem klassischen Timestamp (Datum/Uhrzeit) hat er
    uebrigens nichts zu tun. Weitere Details siehe
    http://msdn.microsoft.com/de-de/library/ms182776%28SQL.90%29.aspx

    Gruss - Peter


    Mitglied im http://www.dbdev.org
    FAQ: http://www.donkarl.com

    Freitag, 5. November 2010 10:15
    Moderator
  • Am 04.11.2010 schrieb Josef Pötzl [MVP]:

    A_SQLDeveloper schrieb:

    Das Formular ist an das ADO.Rexordset gebunden.
    In Access 97 / 2000 war es m.E. möglich vom System erzeugte Meldungen generell zu unterdrücken. Geht das auch in Access 2007?

    Du meinst vermutlich DoCmd.SetWarnings. Ob man damit die
    Schreibkonflikt-Meldung unterdrücken kann, weiß ich allerdings nicht.

    Nein, diese Meldung kann mit Docmd.SetWarnings unterdrückt werden.

    Wäre es nicht besser, das Problem zu beseitigen, statt die
    Problemanzeige zu unterdrücken?

    Jepp, mein ich auch, der OP ist allerdings anderer Ansicht.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 5. November 2010 10:19
  • Am 05.11.2010 schrieb A_SQLDeveloper:

    ich denke wir sollten die Diskussion hier abbechen. Ich bin der Meinung, das bestehende Problem ausführlich beschrieben zu haben.

    Du hast auch ausreichend Lösungsmöglichkeiten angeboten bekommen.
    Nutzen mußt Du sie schon selbst.

    Anstatt immer neu aufgeworfene Fragen zu beantworten, was ich nicht als unbedingt zielführend betrachte, ist mein Problem dennnoch nicht gelöst.

    Hier gibts auch keine Garantie auf eine funktionierende Lösung. Du
    kannst ja auch einen Call bei MS eröffnen, dort bezahlst Du dann für
    eine Lösung.

    Ich bedanke mich jedoch für die angebotenen Ansätze

    Bitte, gern geschehen.

    Servus
    Winfried


    Connect2WSUS: http://www.grurili.de/tools/Connect2WSUS.exe
    GPO's: http://www.gruppenrichtlinien.de
    Community Forums NNTP Bridge: http://communitybridge.codeplex.com/

    Freitag, 5. November 2010 10:21
  • Hallo zusammen,

    Peter herzlichen Dank für die konkreten Hinweise, die mich zumindest in die richtige Richtung geführt haben.

     

    Die Lösung meines Problems ist eigentlich viel trivialer als gedacht und ohne große Verrenkungen.

    ACCESS Optionen ==> Erweitert ==> Erweitert und da "Datenbanken mit Sperrung auf Datensatzebene öffnen" deaktivieren.

    Wir können, so denke ich jetzt abschließend, die Diskussionhier beenden. Mein Problem ist wohl gelöst.

    mfg


    A_SqlDeveloper
    Freitag, 5. November 2010 14:16