Hallo zusammen,
ich muss leider sagen, dass ich sowohl nur (ambitionierter) Laie in Access, als auch Unwissender auf dem Bereich der VBA Programmierung bin. Derzeit versuche ich die alte Excel-Lösung unseres Pfadfinderstammes zur Mitgliederverwaltung in Access 2016 zu übertragen. Aus meinem Studium habe ich noch Kenntnisse über Access und die Konzeption von Datenbanken. Darüberhinaus habe ich mir 2-3 Bücher aus der Bibliothek geliehen, die die Entwicklung einer Access-Datenbank erklären. Grundsätzlich läuft auch alles ganz gut. Doch so langsam stoße ich an meine Grenzen.
Das Problem ist das folgende:
Bisher hat folgende Excel-Formel überprüft, ob die eingegebene IBAN korrekt ist (wobei X160 die zu überprüfende Zelle war):
"=X160="DE"&TEXT((98-REST((62*(1+REST(TEIL(X160;5;8);97))+27*REST(RECHTS(X160;10);97));97));"00")&TEIL(X160;5;8)&TEXT(RECHTS(X160;10);"0000000000")"
Nun sollte in Access natürlich auch die IBAN überprüft werden. Ich habe im Internet folgenden Code gefunden, der dies wohl erledigt: http://www.vbarchiv.net/tipps/tipp_1481-pruefen-von-internationalen-kontonummern-iban-check.html
Leider weiß ich nicht, wie ich diesen anwenden soll. Wie auf der Internetseite beschrieben habe ich den 1. Teil in ein Modul hinzugefügt. Den 2. Teil habe ich (wie beschrieben) in den Code des Formulars gepackt (vgl. Screenshot). Das zu prüfenden Feld im Formular (bzw. der Tabelle) heißt "tblKonto.IBAN". Darüber hinaus habe ich eine Textbox mit Namen "txtIBAN" auf das Formular hinzugefügt.
Leider tut sich nichts ;-( Hätte mich ehrlich gesagt auch überrascht, wenn das so auf Anhieb funktioniert hätte :D Kann mir jemand sagen, was ich machen muss, damit das funktioniert?
Merci
Bendix
Hallo,
sieht doch gar nicht so schlecht aus ;). Der Code zur Prüfung gehört in ein passendes Ereignis - zB OnCurrent des Forms und NachAktualisieren des IBAN-Feldes im Form.
Hallo,
die Ereignisprozedur dürfe falsch sein..
Und wozu brauchst Du ein weiteres Textfeld?
Zur Prüfung des IBAN-Wertes kann z. B. eine Schaltfläche verwendet werden, die bei Klicken die IBAN prüft (und damit die Prüfprozedur aufruft).
Baue im Formular(Entwurfsansicht) eine Schaltfläche mit z. B. dem Namen "btnIbanCheck" ein.
In dessen Eigenschaften klicke unter "Ereignisse/Beim Klicken" auf die rechts stehenden Pünktchen und wähle "Code" aus. Dadurch erscheint der Eintrag "[Ereignisprozedur]" und der VBA-Editor wird geöffnet. Das Prozedurgerüst ist jetzt schon erstellt und es kann dort der Code eingesetzt werden:
Sub btnIbanCheck_Click()
If IBANOK ( Me!Iban) Then
Me!Iban.Forecolor = vbGreen
Else
Me!Iban.Forecolor = vbRed
End If
End Sub
btw: besser den Code als Text hierher kopieren als einen Screenshot als Bild hochladen...
Hallo Bendix,
noch ein allgemeiner Tipp von mir:
Setze den Haken bei der VBA-Option "Variablendeklaration erforderlich", damit in jedes neue Modul automatisch der Eintrag "Option Explicit" eingefügt wird, und füge dies bei allen bestehenden Modulen nachträglich hinzu. Das bewirkt, dass fehlende Deklarationen zu Kompilierfehlern führen, wodurch die "Stabilität" des Codes erhöht wird.
Das gilt übrigens auch für Excel... ;-)
PS:
Welche Office-Version setzt du ein? Ist "Validate" ein neues Ereignis?
Zitat von: DF6GL am März 24, 2016, 10:17:35
Hallo,
die Ereignisprozedur dürfe falsch sein..
Und wozu brauchst Du ein weiteres Textfeld?
Zur Prüfung des IBAN-Wertes kann z. B. eine Schaltfläche verwendet werden, die bei Klicken die IBAN prüft (und damit die Prüfprozedur aufruft).
Baue im Formular(Entwurfsansicht) eine Schaltfläche mit z. B. dem Namen "btnIbanCheck" ein.
In dessen Eigenschaften klicke unter "Ereignisse/Beim Klicken" auf die rechts stehenden Pünktchen und wähle "Code" aus. Dadurch erscheint der Eintrag "[Ereignisprozedur]" und der VBA-Editor wird geöffnet. Das Prozedurgerüst ist jetzt schon erstellt und es kann dort der Code eingesetzt werden:
Sub btnIbanCheck_Click()
If IBANOK ( Me!Iban) Then
Me!Iban.Forecolor = vbGreen
Else
Me!Iban.Forecolor = vbRed
End If
End Sub
btw: besser den Code als Text hierher kopieren als einen Screenshot als Bild hochladen...
Vielen lieben Dank. Das hat super geklappt. Ich fande "Bei Fokusverlust" des Eingabefeldes eine noch bessere Idee, als einen Button drücken zu müssen.
edit: zu früh gefreut. Beim wechsel des Datensatzes bleibt die Farbe erhalten. Gibt es ein Ereignis "bei Datensatzwechsel" oder sowas und wo finde ich das?
Der Code war in dem Link, deswegen habe ich diesen nicht nochmal hier reinkopiert. Der Screenshot war mehr dafür da zu zeigen, wo ich den hingepackt habe :D
@MaggieMay
Danke, hab ich gemacht. Was auch immer das jetzt bewirkt :D
Ich benutze Office 2016.
@el_gomero
Auch an Dich vielen Dank für die schnelle Hilfe!
PS. Könnte sein, dass ich gleich noch 1-2 Fragen habe ::) ::) ::)
Hallo,
Ein bisschen Senf von mir ;)
@Jürgen
OnCurrent halte ich für überflüssig,-muss doch nicht bei jedem DS-Wechsel
validiert werden, wenn das Feld einmal (geprüft) gespeichert wird.
@Bendix
Ich empfehle für Validierungen das Ereignis BeforeUpdate.
Dessen Ereignisprozedur stellt einen Cancel-Parameter zur Verfügung.
Wenn Du den bei IBANOK = False auf True einstellst,Cancel = NOT IBANOK(Me!txtIBAN.Text) bleibt der Cursor im Eingabefeld, und der Anwender muss da nicht extra
wieder reinklicken.
gruss ekkehard
Hi,
OnCurrent wird benötigt für den Farbwechsel, es ist ja nicht auszuschließen, dass falsche IBANs gespeichert werden.
Oder du setzt die bedingte Formatierung ein, dann geht das automatisch.
Okay, ich habe mich jetzt für "Beim Anzeigen" entschieden (hat was gedauert bis ich rausgefunden habe, dass das "on current" ist. Ich glaube das ist das Beste.
Allerdings habe ich das Problem, dass beim erzeugen eines neuen Datensatzes direkt das Ergeignis ausgelöst wird und mit "Laufzeitfehler 94, unzulässige Verwendung von null" abgebrochen wird.
Hier die betroffene Stelle des Codes
Private Sub Form_Current()
[b]If IBANOK(Me!IBAN) Then[/b]
Me!IBAN.ForeColor = vbBlue
Else
Me!IBAN.ForeColor = vbRed
End If
End Sub
Du kannst das Textfeld entweder mit der IsNull-Funktion auf NULL abfragen (falls es auch bei vorhandenen Datensätzen leer bleiben darf) oder du prüfst mit Hilfe von "NewRecord", ob du auf einem neuen Datensatz stehst.
...oder du setzt beim Aufruf der Funktion die NZ-Funktion ein:
If IBANOK(NZ(Me!IBAN)) Then
{Edit: Hinweis auf IsNull() hinzugefügt}
Perfekt das ist es... Danke! Danke! Danke!
Hallo Maggie,
ZitatOnCurrent wird benötigt für den Farbwechsel, es ist ja nicht auszuschließen, dass falsche IBANs gespeichert werden.
Wie denn, wenn die Korrektheit schon bei der Eingabe (TextFeld_BeforeUpdate) geprüft wird.
Ausser natürlich man lässt dann das Speichern einer nicht korrekten IBAN zu. ;)
Oder, - man muss neu
importierte DS überprüfen. Da ist der Farbwechsel sicher hilfreich.
Aber er spricht ja von neuen DSn bei der Erfassung.
Und IsNull kann ich BeforeUpdate auch abfangen.
gruss ekkehard
Ich habe doch noch eine kleine Frage bzw. Problem.
Nach dem Neustert von Access erhalte ich die Fehlermeldung im Anhang. ("(...) Return ohne GoSub"). Dieser wird ausgelöst durch das OnCurrent bzw. KeinFokus Ereignis. Sobald ich den Code einmal im VBA öffne (nur gucken, nichts machen) ist wieder alles okay. Woran liegt das?
Hier die Hilfe zum Fehler (hilft mir nur leider nicht :D)
ZitatDieser Fehler tritt auf, wenn ein Ereignis nicht ausgeführt werden konnte, weil der Speicherort der Logik für das Ereignis nicht ausgewertet werden kann. Falls z. B. die OnOpen-Eigenschaft eines Formulars auf =[Field] festgelegt ist, tritt dieser Fehler auf, weil die Ausführung eines Makros oder Ereignisnamens erwartet wird, wenn das Ereignis auftritt.
Hier der Code
Option Compare Database
Private Sub Form_Current()
If IBANOK(Nz(Me!IBAN)) Then
Me!IBAN.ForeColor = vbBlue
Else
Me!IBAN.ForeColor = vbRed
End If
End Sub
Private Sub IBAN_LostFocus()
If IBANOK(Nz(Me!IBAN)) Then
Me!IBAN.ForeColor = vbBlue
Else
Me!IBAN.ForeColor = vbRed
End If
End Sub
LG
Bendix
Hallo Bendix,
Eine wirkliche Lösung habe ich jetzt zwar nicht. Mir fällt nur Folgendes auf:
Bei den Aufrufen von Nz(Me!IBAN) fehlt der ValueIfNull-Parameter.
Kann zwar IMO nicht daran liegen, da die Prüfprozedur mit vbNullString
eigentlich zurecht kommen müsste (nicht geprüft).
Allgemein fällt auf, dass "Option Explicit" im Modulkopf fehlt. Das gehört
in jedes Modul! VBA erledigt das auch gerne für dich, wenn Du bei
den Optionen im Editor das Häkchen setzt bei "Variablendeklaration erforderlich".
gruss ekkehard
DF6GL hatte sich die Tabelle nochmal wegen einer anderen Sache (vgl. anderen Thread von mir) angenommen. "Seine" Version ist nun ohne diesen Fehler. Was er ausgebessert hat, weiß ich leider nicht.
ZitatAllgemein fällt auf, dass "Option Explicit" im Modulkopf fehlt. Das gehört
in jedes Modul! VBA erledigt das auch gerne für dich, wenn Du bei
den Optionen im Editor das Häkchen setzt bei "Variablendeklaration erforderlich".
Das Häkchen hatte ich erst nachträglich gesetzt. Soll ich einfach "Option Explicit" im Kopf ergänzen?
ZitatEine wirkliche Lösung habe ich jetzt zwar nicht. Mir fällt nur Folgendes auf:
Bei den Aufrufen von Nz(Me!IBAN) fehlt der ValueIfNull-Parameter.
Kann zwar IMO nicht daran liegen, da die Prüfprozedur mit vbNullString
eigentlich zurecht kommen müsste (nicht geprüft).
Soll ich da jetzt was ergänzen oder einfach so lassen?
Hallo,
ZitatWas er ausgebessert hat, weiß ich leider nicht
Solltest Du aber schon erkennen, wenn Du beide Versionen vergleichst..
Soweit ich mich erinnere:
Nz(Me!IBAN,0)
Bei der Beitragshöhe-Berechnung die doppelten/überflüssigen Felder entfernt und die (falschen) Kombis in Textfelder umgewandelt, bzw. neu eingebaut. Beim DomSumme-Kriterium den richtigen Tabellenfeldnamen eingesetzt (vorher stand da der Tabellenname)...
Zitat
Solltest Du aber schon erkennen, wenn Du beide Versionen vergleichst..
Stimmt
,0 Hab ich wohl übersehen.
Zitatdie (falschen) Kombis in Textfelder umgewandelt
Was war falsch an den Kombis? Ehrlich gesagt war das schon mit Absicht so gemacht. Verursacht das Fehler? Ich dachte es wird einfach nur die 1. Spalte ausgeblendet.
ZitatBeim DomSumme-Kriterium den richtigen Tabellenfeldnamen eingesetzt (vorher stand da der Tabellenname)...
Sorry, so war das in meiner "Vorlage" ::)
Hallo,
ZitatWas war falsch an den Kombis?
Wenn das Kombi an das Fremdschlüsselfeld gebunden ist und in Spalte 0 des Kombilistenfeldes der PK der "Nachschlage"-Tabelle steht, ist nichts falsch.
Zu erwähnen wäre noch, dass das nochmalige Verknüpfen einer Tabelle mit einer neuen Abfrage überflüssig ist, wenn diese Tabelle eh schon in der (ersten) Abfrage eingebunden ist.
ZitatWenn das Kombi an das Fremdschlüsselfeld gebunden ist und in Spalte 0 des Kombilistenfeldes der PK der "Nachschlage"-Tabelle steht, ist nichts falsch.
Okay, cool. Genau so ist es.
Zitat
Zu erwähnen wäre noch, dass das nochmalige Verknüpfen einer Tabelle mit einer neuen Abfrage überflüssig ist, wenn diese Tabelle eh schon in der (ersten) Abfrage eingebunden ist.
Hab ich das gemacht? Habe ich das vor? Dachte eigentlich nicht ;D
Hi,
ZitatHab ich das gemacht
Ja... ;)
Meine Datenbank hat doch nur eine Abfrage ;D
Nein,
der Bericht (oder das Formular "Konto", weiß jetzt nicht mehr) hatte in seiner Datenherkunft einen SQL-String (---> Abfrage) in diese "eine Abfrage" nochmal mit tblKonto verknüpft wurde....
Danke. Es war der Bericht, den ich auf Grundlage der Tabelle erstellt hatte. Das ändere ich mal auf eine (neue) Abfrage.