Speichern-Abfrage zweimal ...?

[Jörg Böhmichen]

Hallo NG,
ich verwende Win2K und AccXP.

In einem Formular 'frmKurse' habe ich ein Register-StE
mit drei Seiten; auf den Seiten 1 und 2 sind mehrere
Text- und Kombifelder, auf Seite 3 ein Ufo-StE.

Im Formularkopf ist ein Suchbutton zum Aufrufen
eines Suchformulars.

Wenn ich in einem Textfeld einen Eintrag ändere,
wird das Form 'dirty'. Jetzt klicke ich auf den
Suchbutton, um das Suchformular zu öffnen und zu
einem anderen Kurs umzuschalten. Erst wenn ich einen
anderen Kurs ausgewählt habe und er im Formular ange-
zeigt werden müsste, fragt meine Form_BeforeUpdate-
Routine, ob die o.g. Änderung gespeichert werden soll.
Dann wird der neu ausgewählte Kurs angezeigt.

Um die Änderung(en) im Form gleich zu speichern, wenn
ich den Suchbutton klicke, habe ich bei btnSucheKurs_Click
folgenden Code eingetragen:

Private Sub btnSucheKurs_Click()
Dim MsgText As String, MsgTitel As String
on error GoTo Err_btnSucheKurs
If Me.Dirty Then
MsgText = "Wollen Sie die Änderung speichern?"
MsgTitel = "Speichern?"
If MsgBox(MsgText, vbYesNo, MsgTitel) = vbNo Then
Me.Undo
Else
DoCmd.RunCommand acCmdSaveRecord
End If
End If
DoCmd.OpenForm "frmSucheKurs", , , , , acDialog, Me.Name

Exit_btnSucheKurs:
Exit Sub

Err_btnSucheKurs:
MsgBox "Fehler " & Err & ":" & vbCrLf & Err.Description
Resume Exit_btnSucheKurs
End Sub

Sobald ich jetzt nach einer Änderung im Form, die noch
nicht abgespeichert ist, den Suchbutton klicke, kommt
richtig die Speichern-Abfrage. Nach 'Ja' kommt sie aber
noch ein zweites Mal !!! Warum???

Die Form_BeforeUpdate-Routine kann's nicht sein, weil
noch gar kein anderer DS angezeigt werden soll.
Und Schrittbetrieb, um die Ursache für dieses Verhalten
zu "erforschen", scheitert am Befehl
DoCmd.RunCommand acCmdSaveRecord -- da kommt Fehler 2046.

Wer kann mir helfen?
Vielen Dank!
Jörg

[Henry Habermacher [MVP Access]]

Hallo Jörg

Jörg Böhmichen wrote in news:24c5b01c45fa4$bc07f590$a401...@phx.gbl:

Ich weiss nicht, was in obigem Code falsch läuft, sieht soweit ok aus.
Da muss es noch anderen Code geben, den wir nicht sehen. Ich vermute,
dass Du da noch code beim Form_BeforeUpdate drin hast oder dort eine
Funktion aufrufst. Setze doch einfach mal einen Break nach dem MsgBox
rein und gehe dann step-by-step durch. Dann siehst Du, wo der Code sonst
noch aufgerufen wird.
Evt. ist es auch eine Kompiler Leiche, die hier ihr Unwesen treibt,
vielleicht hattest Du diesen Code mal im Form_Before Update drin und
dann dort rausgenommen, ohne dass es Access bemerkt hat und es führt
diesen Code dort immer noch aus (Korruption im Byte Code). Um
sicherzustellen, dass diese Codeleichen nicht mehr vorhanden sind,
kannst Du versuchen einen /Decompile zu machen, wenn's nichts hilft,
versuch die anderen Methoden zur Datenbankreparatur, die in der FAQ
beschrieben sind.

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

[Jörg Böhmichen]

Hallo Henry,
vielen Dank für Deinen Tipp ...

>-----Originalnachricht-----
>...

>Ich weiss nicht, was in obigem Code falsch läuft, sieht
soweit ok aus.

Freut mich erstmal ...

>... vielleicht hattest Du diesen Code mal im Form_
>BeforeUpdate drin und dann dort rausgenommen ...

Ja, den Code (zumindest die Speicher-Abfrage) hab' ich
aus der Form_BeforeUpdate übernommen, er ist dort aber
auch noch drin. Und das "RunCommand acCmdSaveRecord" ist
im btnDSspeichern_Click drin. An beiden Stellen wird der
Code auch gebraucht! Aber weder die eine noch die andere
Prozedur dürften laufen ...

>Setze doch einfach mal einen Break nach dem MsgBox
>rein und gehe dann step-by-step durch. Dann siehst Du,
>wo der Code sonst noch aufgerufen wird.

>Evt. ist es auch eine Kompiler-Leiche, die hier ihr
>Unwesen treibt, vielleicht ...führt Access ... diesen

>Code dort immer noch aus (Korruption im Byte Code).

Was ist "Korruption im Byte Code"?

>Um sicherzustellen, dass diese Codeleichen nicht mehr
>vorhanden sind, kannst Du versuchen einen /Decompile
>zu machen, wenn's nichts hilft, versuch die anderen
>Methoden zur Datenbankreparatur, die in der FAQ
>beschrieben sind.

O.K., werd ich machen ...

Vielen Dank erstmal!
Jörg

[Henry Habermacher [MVP Access]]

Hallo Jörg

Jörg Böhmichen wrote in news:24d0501c46019$a0b40de0$a301...@phx.gbl:

>> ... vielleicht hattest Du diesen Code mal im Form_
>> BeforeUpdate drin und dann dort rausgenommen ...
>
> Ja, den Code (zumindest die Speicher-Abfrage) hab' ich
> aus der Form_BeforeUpdate übernommen, er ist dort aber
> auch noch drin. Und das "RunCommand acCmdSaveRecord" ist
> im btnDSspeichern_Click drin. An beiden Stellen wird der
> Code auch gebraucht! Aber weder die eine noch die andere
> Prozedur dürften laufen ...

Wieso soll denn der Form_BeforeUpdate nicht anlaufen? Wenn Du einen
acCmdSaveRecord command abschickst, läuft der auf jeden Fall an!!! Mach
doch einfach mal dort einen Stop rein und verfolge was abläuft. Er ist,
würde ich sagen, beim Speichern Button absolut überflüssig. Immer bevor
gespeichert wird, wird der Form_BeforeUpdate anlaufen, das ist eine
Grundregel. Wenn die nicht zutreffen würde, würde wohl keiner meiner
Anwendungen mehr laufen.

Gruss

[Karl Donaubauer]

Jörg Böhmichen wrote:
> ...

Vermutlich, weil du den Code nicht nur beim Button sondern
auch bei BeforeUpdate drin hast.

> Die Form_BeforeUpdate-Routine kann's nicht sein, weil
> noch gar kein anderer DS angezeigt werden soll.

So was in der Art schreibst du auch schon weiter oben.
Nur, wie kommst du darauf?
Ein Speicherbefehl löst immer das Ereignis BeforeUpdate aus.

Hast du dort einen anderen Code, der das Nachfragen etc.
weiter einschränkt? Dann solltest du den Code prüfen oder
gar herzeigen. Wenn's der gleiche ist wie oben, ist die
doppelte Nachfrage logisch.

> Und Schrittbetrieb, um die Ursache für dieses Verhalten
> zu "erforschen", scheitert am Befehl
> DoCmd.RunCommand acCmdSaveRecord -- da kommt Fehler 2046.

>...

Klar, der Speicherbefehl würde ja auch das BeforeUpdate-Ereignis,
in dem er selber steht, wiederum auslösen und sich die Katze bis
zum Umfallen in den Schwanz beißen.

BTW Wenn ich mich richtig erinnere, ist die letzte Infomail über
die AEK an deine Vorjahresadresse gebouncet. Bei Interesse
schau halt auf die AEK-Seite auf meiner u.a. Website.

--
HTH
Karl
********* Ich beantworte keine Access-Fragen per Email. *********
Access-FAQ: http://www.donkarl.com
+ Info zur 7. Access-Entwickler-Konferenz 25./26.9. in Nürnberg