Hallo zusammen.
Ich habe in einem Formular einen Button eingeführt und vom Assistenten "Formular schließen" erzeugen lassen.
Wenn ich aber das Formular schließen möchte, kommt oben genannte Fehlermeldung.
Ich bin nicht so stark wie ihr mit VBA, aber ich verstehe nicht, warum das von Access erzeugte Sub scheinbar nicht funktioniert.
Folgenden Code ist dem Event beim Klick angehängt.
Private Sub cmdCloseFormArzt_Click()
DoCmd.Close acForm, Me.Name, acSaveYes
End Sub
Was habe ich übersehen oder mache ich falsch.
Danke für den Tipp.
VG Peer
Zitat von: Peerli am August 01, 2025, 18:53:37ich verstehe nicht, warum das von Access erzeugte Sub scheinbar nicht funktioniert.
Das Problem sollte nicht an der gezeigten Prozedur liegen.
Wenn du in der VBA-Umgebung Menü "Debuggen" -> "Kompilieren ..." anklickst, kommt dann eine andere Fehlermeldung an einer anderen Stelle?
Hallo,
das acSaveYes ist auch überflüssig.
Hi. Danke für die schnelle Rückmeldung.
Nein, es kommt keine Meldung.
VG
Auch bei dir möchte ich mich für die schnelle Rückmeldung bedanken.
Das speichern des Datensatzes beim Schließen des Formulars kommt nicht von mir ;-)
Sollte das Vorhandensein der Fehler sein?
VG
Hallo,
Das speichern des Datensatzes.... Das ist ein Irrtum, acSaveYes speichert keine Daten. Ein Formular speichert die Daten in der Regel automatisch beim Schließen. acSaveYes speichert einen geänderten Formularentwurf.
Welchen Code gibt es noch im Formular?
Bitte keine vollständigen Beiträge zitieren.
Dann liegt es wohl doch daran?
Das würde auch erklären, warum ich die Meldung nicht immer bekomme.
Hallo,
das glaube ich nicht, dass es daran leigt. Das war nur ein zusätzlicher Hinweis.
Ich habe oben noch eine Frage ergänzt.
Das habe ich jetzt erst realisiert.
Option Compare Database
Option Explicit
Private Sub Arzt_IBAN_AfterUpdate()
If IBANOK(Arzt_IBAN.Text) Then
' Konto-Nr. korrekt
Arzt_IBAN.ForeColor = vbBlack
Else
' Konto-Nr. falsch
Arzt_IBAN.ForeColor = vbRed
MsgBox "IBAN falsch", vbCritical, "IBAN falsch"
Arzt_IBAN.SetFocus
End If
End Sub
Private Sub cmdCloseFormArzt_Click()
DoCmd.Close acForm, Me.Name, acSaveYes
End Sub
Private Sub cmdIBANPaste_Click()
'Stellen Sie sicher, dass das Textfeld aktiv ist
Me.Arzt_IBAN.SetFocus
'Fügt den Inhalt der Zwischenablage in das Textfeld ein
DoCmd.RunCommand acCmdPaste
End Sub
Private Sub cmdIBANRechner_Click()
'BLZ und KtoNr in Zwischenablage ++++++++++++++
Dim strText As String
Dim txtBox1 As Access.TextBox
Dim txtBox2 As Access.TextBox
' Verweis auf die Textfelder im Formular
Set txtBox1 = Me.Controls("txtBLZ") ' Ersetzen Sie "Textfeld1" durch den Namen Ihres ersten Textfeldes
Set txtBox2 = Me.Controls("txtKtoNr") ' Ersetzen Sie "Textfeld2" durch den Namen Ihres zweiten Textfeldes
' Daten aus den Textfeldern auslesen und in eine Variable schreiben
strText = txtBox1
Debug.Print strText
strText = strText & txtBox2
Debug.Print strText
Call Inzwischenablage(strText)
' ' Daten in die Zwischenablage kopieren
' With Application.Clipboard
' .Clear
' .SetText strText
' End With
' Optional: Eine Meldung anzeigen, dass die Daten kopiert wurden
MsgBox "Daten wurden in die Zwischenablage kopiert."
' Speicher freigeben
Set txtBox1 = Nothing
Set txtBox2 = Nothing
' Ende Kopieren in Zwischenalage +++++++++++++++++++++++++++++
DoCmd.OpenForm "frmIBANRechner", acDialog
End Sub
Dies ist alles zum dazugehörigen Formular.
Ich bitte um Nachsicht, für den Anfänger Code.
Hallo Peerli,
da ist in der Tat noch viel Optimierungsbedarf, aber die Fehlermeldung führt meistens in die Irre.
Du solltest deine Datenbank mal reparieren oder/und ein decompile durchführen:
https://www.donkarl.com?FAQ1.21 (https://www.donkarl.com?FAQ1.21)
Gruß Knobbi38
Hallo,
Wenn
IBANOK(Arzt_IBAN.Text)das macht, was ich erwarten würde (Berechnung einer IBAN bzw. Prüfung einer
übergebenen), wäre der ganze C&P-Kram doch völlig überflüssig.
Was passiert denn auf dem "frmIBANRechner"?
gruss ekkehard
P.S.: Bei AfterUpdate brauchst keine .Text mehr, zu dem Zeitpunkt ist das bereits
zur Standardeigenschaft .Value geworden. Ausserdem erhälst du bei .Text eine Fehler-
meldung wenn das Ereignis durch einen Wechsel zu einem anderen Control ausgelöst
wird.
Hallo Ekkehard.
Der Sinn des IBAN-Rechner ist aktuell nur nötig, damit ich aus meinem alten Datenbestand noch die Trennung BLZ und KtoNr habe und sie umrechnen und sie als IBAN hinterlegen möchte. Hintergrund ist, dass ich die alten Datenfelder BLZ und KtoNr danach entfernen möchte.
Ich habe die Absicht (aktuell bin ich noch am probieren), bei Vorhandensein von BLZ und KtoNr, diese in die Zwischenablage zu verschieben und in die entsprechenden Felder in IBANRechner abzurufen, um dann beide Felder als IBAN zu erstellen und dann wieder über die Zwischenablage in das Feld IBAN einzutragen.
Aktuell ist es so...
Ich habe (aus alten Bestand) BLZ und KtoNr. Daraus möchte ich mit dem Button "IBAN Rechner" die beiden Daten in die Zwischenablage kopieren, um sie in das nun öffnende Form IBANRechner in die entsprechenden Felder einzufügen. Dort berechne ich die IBAN anhand der BLZ, KtoNr und des Landes und kopiere die IBAN wieder über die Zwischenablage in das Ausgangs-Form in das Feld "IBAN" zurück.
IBANRechner.jpg
Zur Zeit hänge ich noch am übermitteln von BLZ und KtoNr über die Zwischenablage an Form IBANRechner.
VG Peer
Hallo Perrli,
wenn du eine Funktion hast, welche deine IBAN berechnet, dann kannst du die doch aus deinem ursprünglichem Formular aus aufrufen, da braucht man kein weiteres Formular und schon gar keine Kommunikation zwischen zwei Formularen über die Zwischenablage - das ist so etwas von "bad practice". :o
Um dir wirklich helfen zu können, wäre eine Beispiel-DB hilfreich.
Gruß Knobbi38
Hallo,
@Ulrich Eigentlich reicht die Prozedur, die hinter dem Button "IBAN berechnen" steht.
@Peerli Diese Funktion kannst du doch auch direkt mit dem Button "IBAN Rechner" aufrufen.
Du hast die beiden Felder BLZ und Konto-Nr. da doch auch schon.
Luftcode
Private Sub cmdIBANRechner_Click()
'hier erst eine Prüfung einbauen ob beide benötigten Felder gefüllt sind, dann
Me.txtIBAN = IBANberechnen(Me.txtBLZ, Me.txtKonto)
"IBANberechnen" muss dann beide Werte als Parameter annehmen, und damit die
IBAN berechnen.
Prozedurkopf
Function IBANberechnen(sBLZ As String, Konto As StringOb String der richtige Datentyp ist muss du wissen. Ich hab's erstmal angenommen
wegen Länderkürzel und Leerzeichen.
gruss ekkehard
gruss ekkehard
Hallo Knobbi38.
Vielen Dank für deine Rückmeldung und den Vorschlag, zu helfen.
Du hast natürlich recht, das man im Prinzip nicht über die Zwischenablage gehen muss und den IBAN Rechner in der UF unterbringen kann und sollte. Den Rechner hatte ich schon im Vorfeld in mein Projekt eingebaut, ohne im Blick zu haben, das ich die Funktion weit über den Ursprung hinaus verwenden möchte. Wie schon erwähnt, wollte ich testen, wie es funktioniert, zwei Werte in die Zwischenablage zu kopieren und wieder auszulesen.
Eine Beispiel Datei kann ich wegen der inzwischen aufgebauten Größe nur per Link hochladen und ist für 7 Tage zugänglich.
Mit besten Grüßen und besten Dank im Voraus
Peer
ACHTUNG, Peer,
hast Du in dem bereitgestellten Download Echtdaten stehen gelassen?
DATENSCHUTZ!!
Du weißt nicht, wer hier alles mitliest.
Falls Echtdaten, würde ich den Download so schnell wie möglich wieder entfernen.
O.T.:
@Ulli, Phil, Klaus, Eckehard(?):
ich habe Peers DB gesaugt, er / sie sollte den Download ja wieder vom Netz nehmen.
Frage: Gibt es hier sowas wie PN wie früher beim MOF?
Dann könnte ich Euch die DB (gezippt 2MB) als "stille Post" zustellen.
Ansonsten per E-Mail, Zip-Datei PW-geschützt.
(Habe die .accdb mit MS-Defender geprüft: 0 Bedrohungen)
Bez. Hilfe selbst bin ich selbst raus.
Hallo Werner.
Die (Echt)Daten sind nur Daten, die man im Internet auch findet. Z.B. sind nur die Ärzte echt und die haben ihre Adresse im Netz offen.
Welche Daten wären den noch problembehaftet? Die Rechnungsnummern können keiner echten Person zugeordnet werden.
Habe ich wirklich etwas übersehen?
Gruß Peer
Hallo Peer,
ok, kann sein, dass ich überreagiert habe.
Die Tabelle tbl_PAtient enthält tatsächlich nur 4 Datensätze von Paul Panzer über Mickimaus
bis Hans im Glück ohne Adressen.
Alle anderen Tabellen habe ich mir jetzt nicht im Einzelnen angesehen.
Öffenbar hattest Du dann doch vorher die DB anonymisiert.
Auf den ersten groben Blick sah das anders aus.
Sorry, wollte niemanden am frühen Sonntag Abend aufschrecken.
Alles gut, Werner.
Lieber schaut man nochmal nach und andere drauf.
Trotzdem Danke, dass du dir die Mühe gemacht hast, kurz drüber zu schauen.
VG Peer
Hallo,
ich habe Deine BeispielDB gezippt und in Deinem Beitrag #14 angehängt. Den Link habe ich gelöscht.
Beispiele immer Komprimieren/reparieren (Access Dienstprogramm) dann zippen und dann erst hier hochladen.
Zitat von: PeerliDu hast natürlich recht, das man im Prinzip nicht über die Zwischenablage gehen muss und den IBAN Rechner in der UF unterbringen kann und sollte.
Hier liegt ein Missverständnis vor. Die Funktion für die Berechnung der IBAN gehört in ein Modul und wird dann bei Bedarf mit entsprechenden Argumenten aufgerufen. So kannst du die Funktion dann universell nutzen, wenn man es richtig macht sogar in SQL-Abfragen. Zusätzlich ergibt sich aus so einer Vorgehensweise der Vorteil, daß diese Funktion problemlos an neue Gegebenheiten angepaßt werden kann, ohne das man im aufrufenden Code etwas anpassen muß.
Wenn du wirklich von dem alten BLZ/KTO System auf IBAN umstellen möchtest, reicht es, ein zusätzliches Feld in der Tabelle aufzunehmen und dann per SQL ein Update zu machen. Aber Achtung: es reicht nicht immer, BKZ und KtoNr zusammen zu kopieren und dann die Prüfziffer dafür zu berechnen, es gibt anscheinend auch Sonderfälle und IBAN-Regeln. Genaueres kannst du hier nachlesen:
https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/serviceangebot (https://www.bundesbank.de/de/aufgaben/unbarer-zahlungsverkehr/serviceangebot)
Was deinen ursprünglichen Fehler betrifft, wird es schwer, diesen gezielt zu lokalisieren. Das liegt daran, dass der Code bunt durcheinandergewürfelt ist, kein einheitlicher Programmierstil bzw. keine einheitlichen Namenskonventionen gewählt worden sind und zudem auch noch API-Funktionen verwendet werden, deren Deklarationen verbesserungswürdig sind und ggf. noch andere Risiken bergen. Alleine der Code in mdlZwischenablage müsste sicherlich nochmal überarbeitet werden, den würde ich so nicht verwenden. Selbst das Beispiel von MS (https://learn.microsoft.com/de-de/office/vba/access/concepts/windows-api/send-information-to-the-clipboard) wäre besser, obwohl das auch noch aktualisiert werden müßte (Stichwort PtrSafe, 64Bit).
Warum verwendest du z.B. auf der einen Seite API Funktion zum kopieren von Text in die Zwischenablage, an anderer Stelle aber einfach das DoCmd-Objekt für dieselbe Aufgabe?
Auch würde ich mir überlegen, ob das eigentlich einfache Ribbon vielleicht auch ohne GDIPlus umgesetzt werden könnte. Das würde eine Fehlerquelle weniger bedeuten.
Nur mal so ein paar Anregungen, wo ich noch ein wenig Handlungsbedarf sehe.
Gruß Knobbi38
PS:
Bei dieser Gelegenheit möchte ich noch kurz darauf hinweisen, dass es mit dem DataObject aus MSForms 2.0 zu Fehlfunktionen kommen kann. Dieses funktioniert anscheinend nicht mehr richtig, wenn gleichzeitig der Explorer geöffnet ist. Wenn dieses Objekt für den Datenaustausch mit der Zwischenablage verwendet wird, sollte die Anwendung überarbeitet und auf die entsprechenden API-Funktionen umgestellt werden.PPS:
Und hier noch ein Modul mit zwei einfachen Ersatzfunktionen für o.a. Problem.
etwas O.T., aber vielleicht trotzdem hilfreich:
Es gibt ein Onlineportal www.iban-test.de, das die Möglichkeit bietet, per VBA-Zugriff von dort
aus eine IBAN auf Plausibilität zu prüfen. Anbei eine kleine Excel-Datei, in der ein VBA-Code
zu sehen ist, der 1:1 auch in Access verwendet werden kann. Im Code ist ein von mir beantragter API-Code
für max. 50 Zugriffe / Tag hinterlegt. Ich selbst brauche den fast gar nicht mehr.
Hallo Knobbi38
Mir ist durchaus bewusst, dass der Code in diesem Beispiel sehr verbesserungswürdig ist. Ich habe mir einfach mal eine Datenbank erstellt, in der ich mit Daten und Code, Erfahrungen sammeln möchte und durch viele Beispiele aus dem Netz und in Foren zu schauen, was möglich ist und was nicht.
Für jede Hilfe und Tipps bin ich sehr dankbar. Was ich auch bis jetzt feststellen konnte, das man es einen Profi nicht recht machen kann. Jeder findet einen Mangel. Aber da stehe ich drüber und versuche, die Hilfe und Tipps anzunehmen und es das nächste Mal besser zu machen.
Wenn ich darüber nachdenke, wie lang ich gebraucht habe, um die Beziehungen zu den Tabellen zu verstehen...
Auch die von dir angesprochenen Namenskonventionen waren früher wesentlich schlecht. Einige habe ich aus meiner alten DB von 1997 (Acc97) übernommen und versuche sie peu a peu anzupassen.
Mit dem Thema API habe ich mich noch nicht auseinander gesetzt, daher habe ich leider bis jetzt mit einfachen Code angefangen.
Zum Thema Ribbon kann ich nur sagen, dass der Code durch das Tool RibbonCreator 2021 von Gunter Avenius erzeugt wurde, was es schlussendlich macht... keine Ahnung.
Das Prüfen und Erzeugen der IBAN ist nicht nur dahingehend kompliziert, welche Prüfziffer errechnet wird, sondern auch vom jeweiligen Land abhängig. Dies habe ich erst vor kurzen feststellen müssen. Die Idee mit dem Auslagern in ein extra Modul werde ich beherzigen. Ich muss mir nur noch über das WIE Gedanken machen.
Mein ursprünglicher Fehler trat bis jetzt nicht mehr auf. Ich wollte mit meiner Anfrage wissen, ob dies schon anderen passiert ist und welche Ursachen es hat und welche Möglichkeiten man hat, dies zu korrigieren oder von Haus aus auszuschließen.
Vielen Dank Knobbi38
VG Peer
Zitat von: werner budde am August 04, 2025, 09:14:58etwas O.T., aber vielleicht trotzdem hilfreich:
Hallo Werner.
Den Link bzw das zip-File habe ich mir gleich mal heruntergeladen und werde es mir demnächst anschauen.
Aktuell habe ich das Thema IBAN hintenangestellt, weil ich eine Menge andere Baustellen in dem Projekt habe, wie ihr schon feststellen konntet.
VG
Peer
Hallo Peer,
kein Problem. Wenn du mal wieder eine Baustelle hast, weißt du ja, wie du dieses Forum finden kannst. ;)
Gruß Knobbi38