Bei Eingabe in gebundenes Textfeld wird Feld in der Abfrage NICHT aktualisiert

[Bitsqueezer]

Hallo,

ein Typo ist ein Tippfehler.

Das wurde hier im Forum schon des Öfteren angesprochen. Das habe ich bei aktuellem Code schon angepasst. Hier noch nicht. Allerdings ist der Vorteil von dieser Variant, dass Intellisens arbeiten kann. Gut, wenn ich den Formularnamen mit Form_ am Anfang reinschreibe, dann wirkt auch hier Intellisens und der Compiler kann es prüfen.

Wie kommst Du denn darauf?
Mit dieser Zugriffsvariante:

Code [Auswählen] Erweitern

Forms("frmPopRezeptAlsZutat").Controls("cboZugabeEinheit")kann Dir IntelliSense nicht weiterhelfen, es wird Dir nur die Standard-Eigenschaften und -Methoden eines Formulares listen, aber nicht z.B. Deine Controls darin. Das gleiche mit der Controls-Auflistung, die Du hier verwendest. Die Namen als Strings kannst der Compiler (und auch IntelliSense) nicht verarbeiten. Du könntest auch "Forms("MickyMaus")" schreiben und würdest keinen Fehler vom Compiler erhalten.

Die Syntax mit "Form_" ist mit Vorsicht zu genießen. Ja, geht, Du erhältst dann auch IntelliSense-Unterstützung mit den Controls, aber wenn man so auf ein Formular zugreift und es ist nicht geöffnet, wird es automatisch geöffnet. Das kann zu Problemen führen.

Wenn Du auf das "eigene" Formular zugreifst, dann immer "Me." verwenden.
Wenn Du auf ein anderes Formular zugreifst, und es compilersicher haben möchtest, dann kannst Du eine Klasseninstanzvariable verwenden. Zum Beispiel:

Code [Auswählen] Erweitern

Dim frmMeinFormular As Form_MeinFormular
If CurrentProject.AllForms("MeinFormular").IsLoaded Then
   Set frmMeinFormular = Forms("MeinFormular")
End If
Danach kannst Du "frmMeinFormular" wie "Me" verwenden, nur eben für das entsprechende Formular. Es schadet nichts, davor die Variable auf "Is Nothing" zu testen, falls das andere Formular eben nicht geladen war und somit hier nichts zugewiesen werden konnte.

Danke. Das wusste ich noch nicht, aber hier brauche ich den Datentyp STRING tatsächlich.

Was ja kein Problem ist, Du solltest es nur entsprechend abfangen. Heißt, das ganze mit Nz mit einem Leerstring-Austauschwert zu versehen, dann gibt es keine Fehlermeldung, wenn mal NULL dabei herauskommt.

Ich habe gerade mal nachgeschaut. Das führt zu einer besseren Leistung, weil nicht alle Daten abgerufen werden müssen. Das macht Sinn.

Das ist auf jeden Fall schon mal ein wichtiger Grund.

Das habe ich auch schon gehört. Aber wiedersprichst du dir da nicht im 1. Punkt? Da habe ich deinen Beitrag so verstanden, dass die Fehlermeldung in einen SQL-String übergeben werden soll. Wäre das dann nicht ein zusammengesetzter SQL-String bzw. wäre in diesem Fall, wenn es ein zusammengesetzter SQL-String ist, an dieser Stelle also sinnvoll?

Nein, Du mußt nochmal genau nachlesen.
Im ersten Fall ging es darum, statt einzelner Messageboxen und einzelner Fehlerprüfung alle Fehler zu testen und dann einen Fehlerstring zusammenzusetzen aus allen gefundenen Fehlern und die gesamte Fehlernachricht mit allen gefundenen Fehlern dem Benutzer nur einmal anzuzeigen, so daß er alles korrigieren und dann erfolgreich speichern kann.

Im Fall eines SQL-Strings geht es darum, ein SQL-Kommando als String zusammenzubasteln, und das als Kommando auszuführen. Eine simple Methode, wenn z.B. im WHERE-Teil nach einem String getestet wird, dessen Wert im SQL-String mit "" oder '' umschlossen wird, ist, das als Eingabewert im Feld zu schreiben. Also im ersten Fall ein " und im zweiten Fall ein '.
Da Du die Eingabewerte direkt in das Kommando einbaust, schließt diese Eingabe den String. Das wird bei SQL Injection z.B. gern verwendet, um dann ein Semikolon als Befehlsende einzubauen und einen eigenen SQL-Befehl in das Eingabefeld zu schreiben, z.B. DELETE * FROM tblMeineTabelle". Wie gesagt, mangels Batchfähigkeit geht das in Access-SQL nicht, aber wenn Du das etwa mit ADO auf einem SQL Server ausführst, sehr wohl.

Tatsächlich nutze ich den Compiler und in jedem Modul seht in der ersten Zeile "Option Explicit". Ich arbeite auch mit dem Überwachungsfenster. Sonst wüsste ich gar nicht, wie ich die Fehler alle finden soll.

Das ist auf jeden Fall eine gute Grundlage. Und damit Du daran nicht denken mußt, "Variablendeklaration erforderlich" in den VBA-Editor-Optionen anhaken, dann wird es automatisch bei jedem neuen Modul eingefügt.

Ich empfehle auch, MZTools zu erwerben, das ist nicht teuer und muß nicht ständig neu lizenziert werden. Hier sind etliche Tools drin, die Dir das Leben erleichtern, u.a. auch VBA-Checker, die Deinen Code auf Regeln überprüfen können, wobei Du auch eigene hinzufügen kannst.

Gruß

Christian

[KonradR]

Hallo Christian,

Mit dieser Zugriffsvariante:
Code [Auswählen] Erweitern

Code [Auswählen] Erweitern

Forms("frmPopRezeptAlsZutat").Controls("cboZugabeEinheit")kann Dir IntelliSense nicht weiterhelfen, es wird Dir nur die Standard-Eigenschaften und -Methoden eines Formulares listen, aber nicht z.B. Deine Controls darin.

Das ist was ich mit, Hilfe von Intelisense, meinte. Die Formularnamen werden nicht angezeigt. Die muss ich eingeben oder reinkopieren. Das ist eine Fehlerquelle. Absolut.

Wenn Du auf das "eigene" Formular zugreifst, dann immer "Me." verwenden.
Wenn Du auf ein anderes Formular zugreifst, und es compilersicher haben möchtest, dann kannst Du eine Klasseninstanzvariable verwenden. Zum Beispiel:
Code [Auswählen] Erweitern

Code [Auswählen] Erweitern

Dim frmMeinFormular As Form_MeinFormular
If CurrentProject.AllForms("MeinFormular").IsLoaded Then
   Set frmMeinFormular = Forms("MeinFormular")
End If
Danach kannst Du "frmMeinFormular" wie "Me" verwenden, nur eben für das entsprechende Formular. Es schadet nichts, davor die Variable auf "Is Nothing" zu testen, falls das andere Formular eben nicht geladen war und somit hier nichts zugewiesen werden konnte.

Cool, wieder was gelernt. Vielen Dank.

Das wird bei SQL Injection z.B. gern verwendet, um dann ein Semikolon als Befehlsende einzubauen und einen eigenen SQL-Befehl in das Eingabefeld zu schreiben, z.B. DELETE * FROM tblMeineTabelle". Wie gesagt, mangels Batchfähigkeit geht das in Access-SQL nicht, aber wenn Du das etwa mit ADO auf einem SQL Server ausführst, sehr wohl.

Alles klar. Hier kann also der SQL-String und damit seine Ausführung direkt  verändert werden. Damit können Daten gelöscht werden etc.. Das kann also ganz schön gefährlich werden.

"Variablendeklaration erforderlich" in den VBA-Editor-Optionen anhaken

Check. Das habe ich immer angehakt. Danke nochmal.

Ich empfehle auch, MZTools zu erwerben, das ist nicht teuer und muß nicht ständig neu lizenziert werden

Danke für den Tip. Das schaue ich mir mal an.