Runcommand II

[Thomas Meins]

Hallo NG,

ich bitte um Hilfe bei folgender Frage :

Nach dem Umstieg von 2000 auf 2003, der übrigens ohne Probleme (bis auf das
folgende) gut gelang, tritt der

Fehler 2501 (Die Aktion RunCommand wurde
abgebrochen...) an zwei Stellen im Programm auf.

oder

Fehler 2046
Der Befehl 'Datensatz speichern'Steht zur Zeit nicht zur Verfügung.

DoCmd.RunCommand acCmdSaveRecord
kommt ungefähr 100 x vor, aber nur an zwei Stellen tritt der Laufzeitfehler
auf. Wer hat eine Idee ? Natürlich kann ich den Fehler abfangen, aber wie
kriege ich den Datensatz gespeichert ?

Konfiguration P4, WIN2000, Office 2000, Access 2003. Vielen Dank schon
jetzt.

Gruß aus Hamburg. Thomas

[Henry Habermacher [MVP Access]]

Hallo Thomas

Thomas Meins <d-3...@web.de> wrote:

> DoCmd.RunCommand acCmdSaveRecord
> kommt ungefähr 100 x vor, aber nur an zwei Stellen tritt der
> Laufzeitfehler auf. Wer hat eine Idee ? Natürlich kann ich den Fehler
> abfangen, aber wie kriege ich den Datensatz gespeichert ?
>
> Konfiguration P4, WIN2000, Office 2000, Access 2003. Vielen Dank schon
> jetzt.

Wenn's nur an zwei stellen auftritt, wäre es interessant zu wissen, wo
genau Du das aufrufst. Falls das beim AfterUpdate eines Formulares ist,
könnte das der Grund sein.
Der WEg wäre eigentlich schon richtig, das mit acCmdSaveRecord zu machen
(sagt Karl), ich selber bevorzuge entweder Me.refresh oder Me.Requery.
Auch Me.Dirty = False soll bedingt funktionieren.

Weitere Info findest Du sicher in der FAQ, welche neu auch eine
Suchmaschine beinhaltet.

Gruss
Henry

--
Keine E-Mails auf Postings in NGs senden!
Don't send e-mails to postings in newsgroups!
KB: http://support.microsoft.com/default.aspx
FAQ: http://www.donkarl.com/AccessFAQ.htm
OH: Online Hilfe von Microsoft Access (Taste F1)
Downloads: http://www.dbdev.org

[Peter Doering]

Hallo,

On Wed, 1 Dec 2004 16:45:13 +0100, Thomas Meins wrote:

> Nach dem Umstieg von 2000 auf 2003, der übrigens ohne Probleme (bis auf das
> folgende) gut gelang, tritt der
>
> Fehler 2501 (Die Aktion RunCommand wurde
> abgebrochen...) an zwei Stellen im Programm auf.
>
> oder
>
> Fehler 2046
> Der Befehl 'Datensatz speichern'Steht zur Zeit nicht zur Verfügung.
>
> DoCmd.RunCommand acCmdSaveRecord
> kommt ungefähr 100 x vor, aber nur an zwei Stellen tritt der Laufzeitfehler
> auf. Wer hat eine Idee ? Natürlich kann ich den Fehler abfangen, aber wie
> kriege ich den Datensatz gespeichert ?

Hast du meine Antwort auf dein erstes Posting bekommen?

Gruss - Peter

--
Ich beantworte keine Fragen per Email.
Mitglied im http://www.dbdev.org
FAQ: http://www.donkarl.com

[Peter Doering]

Hallo Henry,

On Wed, 1 Dec 2004 22:56:40 +0700, Henry Habermacher [MVP Access] wrote:

> Der WEg wäre eigentlich schon richtig, das mit acCmdSaveRecord zu machen
> (sagt Karl), ich selber bevorzuge entweder Me.refresh oder Me.Requery.
> Auch Me.Dirty = False soll bedingt funktionieren.

Wieso bedingt?

[Michael Zimmermann]

Hallo!

Henry Habermacher [MVP Access]:

> Der WEg wäre eigentlich schon richtig, das mit

> acCmdSaveRecord zu machen (sagt Karl), ...

Sagt Karl nicht auch Me.Dirty = False?

> ... ich selber bevorzuge entweder Me.refresh oder
> Me.Requery.

Du speicherst /einen/ geänderten DS in einem 200000er
Recordset mit /Requery/? Ist solch großkalibriges
Geschütz dem beschossenen Spätzlein angemessen?

Vom nachherigen Wiederaufsuchen des gespeicherten
Records ganz zu schweigen.

> Auch Me.Dirty = False soll bedingt funktionieren.

Spricht aus Deiner Erfahrung etwas dagegen? Beispiele,
wo es nicht funktioniert?

Gruß aus Mainz
Michael

[Henry Habermacher [MVP Access]]

Hallo Peter

Peter Doering <nos...@doering.org> wrote:

>> Der WEg wäre eigentlich schon richtig, das mit acCmdSaveRecord zu
>> machen (sagt Karl), ich selber bevorzuge entweder Me.refresh oder
>> Me.Requery. Auch Me.Dirty = False soll bedingt funktionieren.
>
> Wieso bedingt?

Ich wage mich an Aussagen eines Kenners dieser Problematik (den ich hier
nicht nennen möchte) erinnern, der mich darauf hingewiesen hat, dass es
da teilweise zu Exceptions kommen könne, schwer reproduzierbar, aber
trotzdem oft angetroffen. Selber verwende ich das nie.

[Henry Habermacher [MVP Access]]

Hallo Michael

Michael Zimmermann <Zimme...@SZWeb.de> wrote:

>> ... ich selber bevorzuge entweder Me.refresh oder
>> Me.Requery.
>
> Du speicherst /einen/ geänderten DS in einem 200000er
> Recordset mit /Requery/? Ist solch großkalibriges
> Geschütz dem beschossenen Spätzlein angemessen?

Na, na, na, davon stand da nichts. Ist selbstverständlich nur in einem
Einzelformular sinnvoll oder in einem Endlosformular, das nur eine
geringe Anzahl Datensätze hat.

>
> Vom nachherigen Wiederaufsuchen des gespeicherten
> Records ganz zu schweigen.

Ist doch bei einem Refresh nicht nötig, der bleibt erhalten.

>
>> Auch Me.Dirty = False soll bedingt funktionieren.
>
> Spricht aus Deiner Erfahrung etwas dagegen? Beispiele,
> wo es nicht funktioniert?

Hast Du mein Posting fertig gelesen? ;-)

[Henry Habermacher [MVP Access]]

Hallo Henry

Henry Habermacher [MVP Access] <DontSp...@psp-online.com> wrote:

> Hast Du mein Posting fertig gelesen? ;-)

Ging gar nicht, das stand gar noch nicht da, du Dupfbacke

Gruss
Ingrid

[Michael Zimmermann]

Hallo!

Henry Habermacher [MVP Access]:

> Michael Zimmermann <Zimme...@SZWeb.de> wrote:
>
> > > ... ich selber bevorzuge entweder Me.refresh oder
> > > Me.Requery.
> >
> > Du speicherst /einen/ geänderten DS in einem 200000er
> > Recordset mit /Requery/? Ist solch großkalibriges
> > Geschütz dem beschossenen Spätzlein angemessen?
>
> Na, na, na, davon stand da nichts. Ist selbstverständlich
> nur in einem Einzelformular sinnvoll oder in einem
> Endlosformular, das nur eine geringe Anzahl Datensätze
> hat.

Okay.

> > Vom nachherigen Wiederaufsuchen des gespeicherten
> > Records ganz zu schweigen.
>
> Ist doch bei einem Refresh nicht nötig, der bleibt
> erhalten.

Ja, aber beim Requery. Von dem habe ich geredet.

> > > Auch Me.Dirty = False soll bedingt funktionieren.
> >
> > Spricht aus Deiner Erfahrung etwas dagegen? Beispiele,
> > wo es nicht funktioniert?
>
> Hast Du mein Posting fertig gelesen? ;-)

/Das/ hat Ingrid ja inzwischen aufgeklärt. ;-)

Wenn ich Deine Andeutungen in Deiner Antwort an Peter
mal aufgreife: Geht das etwas genauer?

Im Hinblick auf den Community-Gedanken und das
Kollektivwissen der Gruppe wäre eine klare
Ansage zielführend. Falls Du Deinen "Informanten"
geheimhalten willst (Fox Mulder? ;-) ), solltest Du
wenigstens ein paar technische Details preisgeben.

Es muß ja wohl mal irgendwie möglich sein, daß wir
es hier schaffen, anhand nachvollziehbarer objektiver
Kriterien eine Standardvorgabe für so einen popeligen
Vorgang wie das Speichern eines DS hinzubekommen.

Wir sollten vielleicht ein für allemal die optimale
Methode ausdiskutieren, und zwar so überzeugend, daß
nachher keiner mehr freiwillig irgend etwas anderes
macht und man das auch guten Gewissens als /die/
Speichermethode empfehlen kann.

Gruß aus Mainz
Michael

[Thomas Meins]

Hallo und vielen Dank an alle !

"Peter Doering" <nos...@doering.org> schrieb im Newsbeitrag
news:31699nF...@individual.net...
> Hallo,

>
> > Nach dem Umstieg von 2000 auf 2003, der übrigens ohne Probleme (bis auf
das
> > folgende) gut gelang, tritt der
> >
> > Fehler 2501 (Die Aktion RunCommand wurde
> > abgebrochen...) an zwei Stellen im Programm auf.
> >
> > oder
> >
> > Fehler 2046
> > Der Befehl 'Datensatz speichern'Steht zur Zeit nicht zur Verfügung.
> >
> > DoCmd.RunCommand acCmdSaveRecord
> > kommt ungefähr 100 x vor, aber nur an zwei Stellen tritt der
Laufzeitfehler
> > auf. Wer hat eine Idee ? Natürlich kann ich den Fehler abfangen, aber
wie
> > kriege ich den Datensatz gespeichert ?
>
> Hast du meine Antwort auf dein erstes Posting bekommen?

Der Fehler scheint daher zukommen, das irgenein Feld nicht exakt der
Gültigkeitsregel entspricht. Das wurde wohl noch in 2000 toleriert, in 2003
offensichtlich nicht mehr.

Es wäre wirklich schön, für das profane Speichern eines DS eine Gültige
Regel/Empfehlung zu haben !

Gruß aus Hamburg. Thomas

[Peter Doering]

Hallo,

On Wed, 1 Dec 2004 18:25:59 +0100, Thomas Meins wrote:
> "Peter Doering" <nos...@doering.org> schrieb im Newsbeitrag
> news:31699nF...@individual.net...
>>

>>> Fehler 2501 (Die Aktion RunCommand wurde abgebrochen...) an zwei
>>> Stellen im Programm auf.
>>>
>>> oder
>>>
>>> Fehler 2046 Der Befehl 'Datensatz speichern'Steht zur Zeit nicht zur
>>> Verfügung.
>>

>> Hast du meine Antwort auf dein erstes Posting bekommen?
>
> Der Fehler scheint daher zukommen, das irgenein Feld nicht exakt der
> Gültigkeitsregel entspricht. Das wurde wohl noch in 2000 toleriert, in 2003
> offensichtlich nicht mehr.

Wenn Gueltigkeitsregeln verletzt werden, helfen auch keine alternativen
Speichermethoden. Da muss die Regel eingehalten oder geaendert werden,
falls die Regel nicht stimmt.

> Es wäre wirklich schön, für das profane Speichern eines DS eine Gültige
> Regel/Empfehlung zu haben !

Ich bleibe bei meiner Empfehlung

Me.Dirty = False

bis mich jemand vom Gegenteil ueberzeugt.

[Michael Zimmermann]

Hallo!

Thomas Meins:

> Der Fehler scheint daher zukommen, das irgenein Feld
> nicht exakt der Gültigkeitsregel entspricht.

Daß dann das Speichern nicht zugelassen wird, ist aber
ganz im Sinne des Erfinders.

> Das wurde wohl noch in 2000 toleriert, in 2003
> offensichtlich nicht mehr.

Kann ich mir nicht vorstellen. Auch ältere A-Versionen
konnten Gültigkeitsregeln erzwingen. Wäre ja schlimm,
wenn nicht.

> Es wäre wirklich schön, für das profane Speichern eines
> DS eine Gültige Regel/Empfehlung zu haben !

Normalerweise würde ich
Me.Dirty = False
empfehlen, vorbehaltlich Henrys Einwand, den wir
hoffentlich noch ausdiskutieren.

Als Alternative ab A 2000
Me.Recordset.Move 0
Das ist fast genauso schnell.

Von Henrys Requery zum Speichern halte ich persönlich
nichts; Refresh könnte man noch erwägen.

Von DoCmd.RunCommand halte ich gar nichts. Einmal die
Involvierung des Makro-Interpreters, zum anderen eine
Stilfrage: Unter Programmieren stelle ich mir etwas
anderes vor, als das plumpe Aufrufen von Befehlen mittels
vordefinierter Zahlenkonstanten.

Gruß aus Mainz
Michael

[Ulf Knochenhauer]

Hallo,

> Ich bleibe bei meiner Empfehlung
>
> Me.Dirty = False
>
> bis mich jemand vom Gegenteil ueberzeugt.
>

geht das auch im adp mit SQL Server?
Ich mache bisher immer Requery und danach suchen aktueller Datensatz.
Das arbeitet aber nicht immer korrekt. Es gibt da gewisse Laufzeiteffekte.
Wenn ich z. B. nach Requery des Formulars und springen zu dem vorher
aktuellen Datensatz noch ein Requery auf ein Kombinationsfeld mache, bekomme
ich Sanduhr und defekte Datenbank (A2003). Dasselbe wenn ich vor dem Aufruf
eines Berichtes ein Requery mache. Ich weiss, das gehört in die andere NG,
aber wo wir hier grad über Speichern eines Datensatzes diskutieren ...
Grüße aus Dresden
Ulf
--

[Peter Doering]

Hallo,

On Thu, 2 Dec 2004 07:16:41 +0100, Ulf Knochenhauer wrote:

>> Ich bleibe bei meiner Empfehlung
>>
>> Me.Dirty = False
>>
>> bis mich jemand vom Gegenteil ueberzeugt.
>
> geht das auch im adp mit SQL Server?

Ja. Gerade mit per OLEDB gelinkter Tabelle getestet.

[Henry Habermacher [MVP Access]]

Hallo Michael

Michael Zimmermann <Zimme...@SZWeb.de> wrote:

> Wenn ich Deine Andeutungen in Deiner Antwort an Peter
> mal aufgreife: Geht das etwas genauer?
>
> Im Hinblick auf den Community-Gedanken und das
> Kollektivwissen der Gruppe wäre eine klare
> Ansage zielführend. Falls Du Deinen "Informanten"
> geheimhalten willst (Fox Mulder? ;-) ), solltest Du
> wenigstens ein paar technische Details preisgeben.

Absolut recht, nur habe ich auch keine genaueren Details, weil ich es
eben auch nie braucht. Es ging damals darum, was besser sei, ein
Refresh, Requery, der Einsatz des DoCmd Objektes für das sichern des
aktuellen Records oder eben das Me.Dirty. IIRC hat damals Karl darauf
hingewiesen, dass mit der (nicht) dokumentierten Variante Me.Dirty =
False teilweise Exceptions beobachtet werden. Ich hatte bis dahin nicht
mal gewusst, dass Me.Dirty Read/Write fähig ist. Ich selber benutze,
wann immer es notwendig ist, Me.Refresh, damit die Änderungen in der
Datenbank gespeichert und allfällige Änderungen in der Datenbank im
Formular sichtbar werden, nicht zu letzt, weil ich einfach das
ErrorHandling des DoCmd Objektes für ziemlich unterentwickelt halte und
nicht jeweils Fehler im Form_Error Event abfangen will, sondern diese
gerne gleich da handle, wo sie auftreten.

Wenn ich mehr herausbekomme (mit gurgeln bisher nichts gefunden), werde
ich das Dir mitteilen.

[Karl Donaubauer]

Hallo, Michael!

Michael Zimmermann wrote:
> Karl Donaubauer:
>> ... Ich konnte mich zwar an keinen Einwand gegen
>> Me.Dirty = False erinnern,... Jedenfalls habe ich
>> nix gefunden außer ein paar Empfehlungen dafür.
>
> Also, nehmen wir das jetzt alle?

Aawoh, jeder, was er will und kann im Access-Wildwuchs.

> ...
>> Natürlich habe ich's meistens nur neben RunCommand
>> AcCmdSaveRecord erwähnt, weil das so schön sprechend
>> ist. :-)
>
> Warum nicht gleich Makros? Die sprechen sogar deutsch.
> ;-)

Kein Problem. Ich gebe in den NGs immer wieder gerne Hilfe dazu.
Makros sind einer der Gründe für die Popularität von Access, so
wie mach andere Dinge, die dir am Produkt und seiner praktischen
Verwendung nicht passen.
Zum Glück warst du nicht der Zuständige bei MS für die Konzeption
von Access. Sonst wären wir alle nicht hier.

--
:-)
Karl
*********
Access-FAQ: http://www.donkarl.com

[Michael Zimmermann]

Hallo!

Karl Donaubauer:
> Michael Zimmermann wrote:
> > > Me.Dirty = False ...

> > Also, nehmen wir das jetzt alle?
>
> Aawoh, jeder, was er will und kann im Access-Wildwuchs.

Man bekommt es hier als Hardcore-Purist nicht
leichtgemacht.

> > Warum nicht gleich Makros? Die sprechen sogar deutsch.
> > ;-)
>
> Kein Problem. Ich gebe in den NGs immer wieder gerne
> Hilfe dazu.

Stimmt, eine gewisse Volksnähe kann man Dir da nicht
absprechen. ;-)

> Makros sind einer der Gründe für die Popularität von
> Access, so wie mach andere Dinge, die dir am Produkt
> und seiner praktischen Verwendung nicht passen.

"Nicht passen" ist vielleicht der falsche Ausdruck. Es
klingt, als würde ich tatsächlich darunter leiden.

Es gibt eben Vorgehensweisen, die ich für professioneller
halte als andere Möglichkeiten, wofür ich, glaube ich,
meist auch gute Gründe anführe(n kann). Dann rate ich
natürlich zu ersteren.

Die von Dir angesprochene "Einfachheit" von Access hat
nämlich auch ihre Schattenseiten: Sie führt m. E. dazu,
daß mit Access erstellte Lösungen häufig keinen Schuß
Pulver wert sind, weil gnadenlos drauflosgeexcelt wird.

In der Folge wird Access als professionelles Werkzeug
häufig nicht ernstgenommen - was nun wirklich nicht
Accessens Schuld ist.

> Zum Glück warst du nicht der Zuständige bei MS für die
> Konzeption von Access.

Als *der* Zuständige wäre ich wahrscheinlich übers
Ziel hinausgeschossen und Access bestünde aus einer
hochkomfortablen schwarzen Konsole, die bei der
Anmeldung zunächst mal abfragt, ob der Benutzer
überhaupt Latein kann. ;-)

Als *einer* der Zuständigen hätte ich aber sicher auch
einige Anregungen geben können, wie man manches etwas
konsequenter auch gehobenem Anspruch zuträglicher hätte
gestaltet haben können.

> Sonst wären wir alle nicht hier.

Na ja, wären wir halt in der Fox-Pro-Gruppe. ;-)

Gruß aus Mainz
Michael

[Karl Donaubauer]

Hallo, Henry!

Henry Habermacher [MVP Access] wrote:

>...IIRC hat damals Karl darauf

> hingewiesen, dass mit der (nicht) dokumentierten Variante Me.Dirty =

> False teilweise Exceptions beobachtet werden...

Ich bin erst jetzt dazu gekommen, meine eigenen alten Postings
durchzuschauen. Ich konnte mich zwar an keinen Einwand gegen
Me.Dirty = False erinnern, aber wer weiß, was man so zusammen
schreibt über die Jahre. Jedenfalls habe ich nix gefunden außer
ein paar Empfehlungen dafür. Natürlich habe ich's meistens nur

neben RunCommand AcCmdSaveRecord erwähnt, weil das so
schön sprechend ist. :-)

--
cu
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com

[Michael Zimmermann]

Hallo!

Karl Donaubauer:

> Henry Habermacher [MVP Access] wrote:
> > ...IIRC hat damals Karl darauf
> > hingewiesen, dass mit der (nicht) dokumentierten
> > Variante Me.Dirty = False teilweise Exceptions
> > beobachtet werden...
>

> ... Ich konnte mich zwar an keinen Einwand gegen
> Me.Dirty = False erinnern,... Jedenfalls habe ich

> nix gefunden außer ein paar Empfehlungen dafür.

Also, nehmen wir das jetzt alle? Tu quoque, Henrice fili!

> Natürlich habe ich's meistens nur neben RunCommand
> AcCmdSaveRecord erwähnt, weil das so schön sprechend
> ist. :-)

Warum nicht gleich Makros? Die sprechen sogar deutsch.
;-)

Gruß aus Mainz
Michael, auch bei der Nachtschicht

[Thomas Möller]

Hallo Michael,

Michael Zimmermann <Zimme...@SZWeb.de> schrieb:

>> Zum Glück warst du nicht der Zuständige bei MS für die
>> Konzeption von Access.
>
> Als *der* Zuständige wäre ich wahrscheinlich übers
> Ziel hinausgeschossen und Access bestünde aus einer
> hochkomfortablen schwarzen Konsole, die bei der
> Anmeldung zunächst mal abfragt, ob der Benutzer
> überhaupt Latein kann. ;-)

ROFTL

>> Sonst wären wir alle nicht hier.

Ich habe ja schon häufig genug unter Beweis gestellt, dass Access unter
diesen Voraussetzungen viel zu hoch für mich wäre. Und so lange es noch
keine Online-Übersetzung für Latein gibt sehe auch viele andere Mitstreiter
hier im Off.

Aber wahrscheinlich hättest Du dann auch in die Entwicklungsgeschichte von
SQL eingegriffen. Aus dem ursprünglichen SEQL (Structured English Query
Language) wäre dann ein SLQL (Structured *Latin* Query Language) geworden.
Mal abgesehen davon, dass das keiner hätte aussprechen können, hätten
wahrscheinlich noch weniger Leute verstanden, was Sie da im Abfrageeditor
zusammengeklickt haben.

SCNR
--
Thomas

Homepage: www.team-moeller.de

TM-Änderprotokoll: Version 2.10 (seit 17.11.2004)
Wer hat wann welchen Datensatz wie geändert?

[Michael Zimmermann]

Thomas Möller:

> Aber wahrscheinlich hättest Du dann auch in die
> Entwicklungsgeschichte von SQL eingegriffen. Aus dem
> ursprünglichen SEQL (Structured English Query Language)
> wäre dann ein SLQL (Structured *Latin* Query Language)
> geworden. Mal abgesehen davon, dass das keiner hätte

> aussprechen können, ...

Trink mal ein paar Späte Binding, dann geht Dir "SLQL"
irgendwann wie von selbst über die Lippen...

[Henry Habermacher [MVP Access]]

Hallo Michael

Michael Zimmermann <Zimme...@SZWeb.de> wrote:

> Also, nehmen wir das jetzt alle? Tu quoque, Henrice fili!

Selbstverständlich!

Jetzt ist alles klar.