none
Docmd.RunCommand acSaveRecord löst Fehler aus

    Frage

  • Ich benutze den obigen Code um meinen Datensatz zu speichern, falls geändert, bevor ich ein weiteres Formular basierend auf den neuen Daten öffne.

    Alspo etwa so:

    if Me.Dirty then

    Docmd ....

    end if

    Die Daten werden af enem SQL-Server gespeichert.

    Nun kommt es relativ (also nicht jedes Mal) vor, dass die DoCmd-Zeile einen Fehler auslöst (ich habe mir beim letzten Auftauchen leider nicht den Code gemerkt, es könnte aber 2046 sein oder 3705).

    Verusche ich dann den Code von der fehlerhaften Zeile aus weiter auszuführen, dann funktioniert das problemlos, wie als bräuchte das Speichern (nur) mehr Zeit.

    Zu diesem Thema fan ich dann den Hinweis, man solle Me.DIrty=false setzen. Aber wieso ? 

    Löst .Dirty=false denn das Speichern selber aus ? Und warum soll das weniger kritisch arbeiten ?

    Dienstag, 13. Januar 2015 17:58

Antworten

  • Hallo!

    Naja, die Fehlermeldung und -nummer wäre schon ein bissel relevant. ;-)

    Joo, Me.Dirty=False löst das Speichern des aktuellen Datensatzes aus.

    Die RunCommand-Aktion führt hingegen den entsprechenden Menü- oder Ribbonpunkt aus. Der wird manchmal per Fehlermeldung als "nicht verfügbar" angemeckert, obwohl er es eigentlich sein sollte.

    Dieses Problem fällt bei Me.Dirty = False weg. Zudem wird im Gegensatz zum RunCommand das Objekt spezifiziert, in dem das Speichern stattfinden soll. Das macht die Sache nochmal sicherer.

    Wenn die Dirty-Methode einen Fehler schmeißt, dann gibt's i.d.R. wirklich inhaltliche Gründe.


    cu
    Karl
    ******
    Access FAQ (de/it): http://www.donkarl.com
    Access Lobby: http://www.AccessDevelopers.org

    • Bearbeitet Karl DonaubauerMVP Mittwoch, 14. Januar 2015 16:41
    • Als Antwort markiert NicoNi Sonntag, 25. Januar 2015 06:46
    Mittwoch, 14. Januar 2015 16:41

Alle Antworten

  • Am 13.01.2015 schrieb NicoNi:

    Die Daten werden af enem SQL-Server gespeichert.

    Nun kommt es relativ (also nicht jedes Mal) vor, dass die DoCmd-Zeile einen Fehler auslöst (ich habe mir beim letzten Auftauchen leider nicht den Code gemerkt, es könnte aber 2046 sein oder 3705).

    Weshalb benutzt Du dann nicht eine SP die den Datensatz per INSERT
    oder MERGE anfügt? Würde ich zumindest bei einer neuen Anwendung
    machen, wenn das Backend auf einem SQL Server ist.


    Servus
    Winfried

    Gruppenrichtlinien
    HowTos zum WSUS Package Publisher
    WSUS Package Publisher
    HowTos zum Local Update Publisher
    NNTP-Bridge für MS-Foren

    Dienstag, 13. Januar 2015 22:24
  • Hallo!

    Naja, die Fehlermeldung und -nummer wäre schon ein bissel relevant. ;-)

    Joo, Me.Dirty=False löst das Speichern des aktuellen Datensatzes aus.

    Die RunCommand-Aktion führt hingegen den entsprechenden Menü- oder Ribbonpunkt aus. Der wird manchmal per Fehlermeldung als "nicht verfügbar" angemeckert, obwohl er es eigentlich sein sollte.

    Dieses Problem fällt bei Me.Dirty = False weg. Zudem wird im Gegensatz zum RunCommand das Objekt spezifiziert, in dem das Speichern stattfinden soll. Das macht die Sache nochmal sicherer.

    Wenn die Dirty-Methode einen Fehler schmeißt, dann gibt's i.d.R. wirklich inhaltliche Gründe.


    cu
    Karl
    ******
    Access FAQ (de/it): http://www.donkarl.com
    Access Lobby: http://www.AccessDevelopers.org

    • Bearbeitet Karl DonaubauerMVP Mittwoch, 14. Januar 2015 16:41
    • Als Antwort markiert NicoNi Sonntag, 25. Januar 2015 06:46
    Mittwoch, 14. Januar 2015 16:41
  • Okay, ich werde es probieren.
    Mittwoch, 14. Januar 2015 17:01
  • Durch die (versuchte) Umstellung auf SQL-Server werden mehr und mehr Dinge per SP erledigt. Ist aber sehr arbeitsaufwändig.

    Tatsache ist, daß ich immer noch verusch ezu vermeiden, alles "zu Fuss" zu machen - eigentlich sollte Access das doch erledigen. Oder worin sonst sollte der Charme von Access liegen ?

    Auf jeden Fall kann ich sagen, daß diese verflixte Umstellung jede Menge Scherereien mit sich bringt! Nur gut, daß ich damit nur wenige Brötchen verdienen muss

    Mittwoch, 14. Januar 2015 17:04
  • Am 14.01.2015 schrieb NicoNi:

    Durch die (versuchte) Umstellung auf SQL-Server werden mehr und mehr Dinge per SP erledigt. Ist aber sehr arbeitsaufwändig.

    Jepp, ich weiß. ;)

    Tatsache ist, daß ich immer noch verusch ezu vermeiden, alles "zu Fuss" zu machen - eigentlich sollte Access das doch erledigen. Oder worin sonst sollte der Charme von Access liegen ?

    Hast Du schon mal in .Net eine Anwendung mit einem Datenbankzugriff
    erstellt? IMHO geht in Access alles sehr viel einfacher. Berichte und
    Formulare. Und so eine kleine SP ist doch recht schnell erstellt,
    oder? ;)

    Auf jeden Fall kann ich sagen, daß diese verflixte Umstellung jede Menge Scherereien mit sich bringt! Nur gut, daß ich damit nur wenige Brötchen verdienen muss

    Naja, sehe es als Bereicherung. Das Wissen kann dir anschließend
    niemand mehr nehmen. Ich hab4 Anwendungen die ich Schritt für Schritt
    umstelle. Da kommt auch einiges zusammen.


    Servus
    Winfried

    Gruppenrichtlinien
    HowTos zum WSUS Package Publisher
    WSUS Package Publisher
    HowTos zum Local Update Publisher
    NNTP-Bridge für MS-Foren

    Mittwoch, 14. Januar 2015 17:15
  • Die Me.Dirty-Geschichte scehint zu funktionieren

    Danke

    Sonntag, 25. Januar 2015 06:46