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!
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
Zitat von: itsaaccess am Juni 24, 2016, 01:37:39hab 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.
"Debug.Print" ist dein Freund ;)
Hallo,
Zitat von: PhilS am Juni 24, 2016, 09:05:19
Ü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:
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?
Hallo,
man sollte möglichst immer von Parameterabfragen Gebrauch machen, statt Abfragetexte zusammenzuschustern.
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
Zitat von: Lachtaube am Juni 27, 2016, 03:39:36
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.
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
Danke, an den letzten Punkt hätte ich z.B. nicht gedacht.
LG Markus
@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
Zitat von: markus888 am Juni 28, 2016, 09:54:23vielleicht 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.
...WHERE (einFeld = [@einParam]
OR [@einParam] IS NULL)
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.
Zitat von: PhilS am Juni 28, 2016, 11:04:40
Finde ich nicht.
...WHERE (einFeld = [@einParam]
OR [@einParam] IS NULL)
@Phils
hast recht, von der Logik her sollte es so gehen (ungeprüft).
LG Markus