Dauernd Syntax-Probleme

[itsaaccess]

Hallo,
hab mal wieder ein Sytaxproblem, bei Value-Übergabe.
Wenn man googelt steht überall was anders.
Könnte bitte jemand die Value-Zeile korrigieren.
Es ist immer irgendwie ein Fehler drin.
Vielen Dank!

Code [Auswählen] Erweitern

Private Sub button_reflist_setzen_Click()
Dim str As String, Buchung As Integer, Name As String, Vorname As String, IBAN As String, Personalnummer As Integer
Buchung = Me.Buchung_ID
Name = Me!Name
Vorname = Me.Vorname
If IsNull(Me.IBAN) Or Me.IBAN = "" Then IBAN = "Bitte_nachtragen" Else IBAN = Me.IBAN

Personalnummer = Me.Personalnummer

str = "INSERT INTO " & _
"tb_mandatsreferenznummer_beantr(Buchung_ID, Name, Vorname, IBAN, Personalnummer) " & _
"VALUES(" & Buchung & ", " ' & Name & '", "' & Vorname & '", "' & IBAN & '", "' & Personalnummer & '")"

DoCmd.RunSQL str

End Sub



[PhilS]

hab mal wieder ein Sytaxproblem, bei Value-Übergabe.
Wenn man googelt steht überall was anders.
Könnte bitte jemand die Value-Zeile korrigieren.

Doppelte Anführungszeichen (") begrenzen die Teil-Strings in VBA.
Einfache Anführungszeichen (') begrenzen die Literale (Zeichenfolgen) im SQL.
Schreib dir doch erstmal das SQL zum Einfügen eines Beispieldatensatzes in einem Texteditor. Wenn du dann überlegst, wie du den konstanten String ändern musst, um in VBA die Werte der Variablen einzufügen, solltest du schnell sehen, wo der Fehler ist.

Übrigens, Name ist ein ungünstiger Bezeichner für Felder und Variablen. Dies ist ein reserviertes Wort in Access.

[Beaker s.a.]

"Debug.Print" ist dein Freund 

[MaggieMay]

Hallo,

Übrigens, Name ist ein ungünstiger Bezeichner für Felder und Variablen. Dies ist ein reserviertes Wort in Access.

und Str() ist der Name einer Funktion, so solltest du also besser keine Variable nennen.

Was die Verkettung von Variablen und Textstrings betrifft, so solltest du es damit etwas genauer nehmen.
Anführungsstriche müssen immer paarig eingesetzt werden.
So sollte das klappen:

Code [Auswählen] Erweitern

str = "INSERT INTO " & _
          "tb_mandatsreferenznummer_beantr(Buchung_ID, Name, Vorname, IBAN, Personalnummer) " & _
          "VALUES(" & Me!Buchung & ",  '" & Me!Name & "', '" & Me!Vorname & "', '" & Me!IBAN & "', '" & Me!Personalnummer & "')"


BTW:
Die Variablen "Buchung", "Name", "Vormame", "Personalnummer" und "IBAN" sind hier im übrigen völlig überflüssig.

Personalnummer ist ein Text?

[Lachtaube]

Hallo,

man sollte möglichst immer von Parameterabfragen Gebrauch machen, statt Abfragetexte zusammenzuschustern.

Code [Auswählen] Erweitern

Private Sub button_reflist_setzen_Click()
   'besser als gespeicherte Abfrage verwenden
   '
   'optional könnte noch eine Parameterdefinition vorangestellt werden
   Const APP_REF_NO_REQ = _
         "INSERT INTO tb_mandatsreferenznummer_beantr(" & _
         "  Buchung_ID" & _
         ", Name" & _
         ", Vorname" & _
         ", IBAN" & _
         ", Personalnummer) " & _
         "VALUES(" & _
         "  [@Buchung_ID]" & _
         ", [@Name]" & _
         ", [@Vorname]" & _
         ", [@IBAN]" & _
         ", [@Personalnummer])"

   On Error GoTo e

   If IsNull(Me.Buchung_ID) _
      Or IsNull(Me!Name) _
      Or IsNull(Me.Vorname) _
      Or IsNull(Me.Personalnummer) Then

      MsgBox "Unvollständige Daten"
      Exit Sub

   End If

   With CurrentDb().CreateQueryDef(vbNullString, APP_REF_NO_REQ)
      'bzw.
   'With CurrentDb().QueryDefs("Name_der_gespeicherten_Abfrage")
      .Parameters("@Buchung_ID") = Me.Buchung_ID
      .Parameters("@Name") = Me!Name
      .Parameters("@Vorname") = Me.Vorname
      .Parameters("@IBAN") = Nz(Me.IBAN, "Bitte_nachtragen")
      .Parameters ("@Personalnummer")
     
      .Execute dbFailOnError
   End With

   Exit Sub

e:
   MsgBox Err.Description
End Sub

[markusxy]

Hallo,

man sollte möglichst immer von Parameterabfragen Gebrauch machen, statt Abfragetexte zusammenzuschustern.

Vielleicht könntest du das auch begründen, damit die User den Vorteil dieser Vorgehensweise erkennen.

[Lachtaube]

a) wegen der Einfachheit der Handhabung - übergib mal einen Null-Wert aus einem Steuerelement und vergleiche den Aufwand
b) weil Access-Parameter typensicher sind
c) Verhinderung von SQL-Injection

[markusxy]

Danke, an den letzten Punkt hätte ich z.B. nicht gedacht.

LG Markus

[markusxy]

@Lachtaube

vielleicht sollte man aber noch anfügen, dass die Verwendung eines Parameters mit Null im where Bereich ein Problem darstellt und nicht funktioniert und man dann wieder "zusammenstoppeln" muss.

Und einfach Daten in eine Tabelle einfügen ohne Vorher etwas zu prüfen mag ja vorkommen. Bei mir eher nicht. Daher ist die Parameter Sache sehr unglücklich und man ist besser bedient wenn man eine eigene Funktion verwendet, die auch im where Bereich korrekt arbeitet alternativ <BuildCriteria>.

LG Markus

[PhilS]

vielleicht sollte man aber noch anfügen, dass die Verwendung eines Parameters mit Null im where Bereich ein Problem darstellt und nicht funktioniert und man dann wieder "zusammenstoppeln" muss.

Finde ich nicht.

Code [Auswählen] Erweitern

...WHERE (einFeld = [@einParam]
    OR [@einParam] IS NULL)

[ebs17]

Einige Einzeldaten als einen Datensatz an eine Tabelle  anzufügen - da ist ein Recordset-AddNew von der Performance her gleichwertig und in der Durchführung übersichtlicher.
Gleichwohl sollte man (richtige) Parameterabfragen sowie auch das "Zusammenstoppeln" von SQL-Anweisungen beherrschen.

[markusxy]

Finde ich nicht.

Code [Auswählen] Erweitern

...WHERE (einFeld = [@einParam]
    OR [@einParam] IS NULL)

@Phils
hast recht, von der Logik her sollte es so gehen (ungeprüft).
LG Markus