DoCmd.RunSQL INSERT INTO - Syntaxfehler

[Steven Prohaska]

Hallo NG'ler,

ich stehe gerade etwas auf dem Schlauch, erhalte bei folgenden Code
Laufzeitfehler 3134: Syntaxfehler in der INSERT INTO-Anweisung:

DoCmd.RunSQL
"INSERT INTO " & rezarc & "SELECT " & rez & ".* FROM " & rez & ";"

(rezarc und rez sind als Variablen deklariert)

Weiß jemand Rat ?

Gruß - Steven

[Michael Zimmermann]

Hallo Steven!

Post by Steven Prohaska
ich stehe gerade etwas auf dem Schlauch, erhalte bei
folgenden Code Laufzeitfehler 3134: Syntaxfehler in der
DoCmd.RunSQL

Ersetze das durch CurrentDb.Execute SQLCode, dbFailOnError
Das löst zwar nicht Dein Problem, ist aber RunSQL
vorzuziehen.

Post by Steven Prohaska
"INSERT INTO " & rezarc & "SELECT " & rez & ".* FROM " &
rez & ";"
(rezarc und rez sind als Variablen deklariert)

"INSERT INTO " & rezarc & " SELECT " & rez & ".* FROM "...
^^^
Versuch mal, ob es das war (Leerzeichen). Wenn nicht,
müßtest Du den Inhalt Deiner Variablen preisgeben.

Gruß aus Mainz
Michael

[Karl Donaubauer]

Post by Steven Prohaska
ich stehe gerade etwas auf dem Schlauch, erhalte bei folgenden Code
DoCmd.RunSQL
"INSERT INTO " & rezarc & "SELECT " & rez & ".* FROM " & rez & ";"
(rezarc und rez sind als Variablen deklariert)

Es fehlt ein Leerzeichen bei: " SELECT "

BTW
Ich nehme zum Testen wegen der Meldungen auch gerne RunSQL.
Im Ernstfall dann aber eher Execute, weil's schneller ist, man die
Access-Meldungen nicht wegschalten muss und das Abbrechen
bei Fehler sicherer ist. Das 1. rez kannst du auch noch wegkürzen.
Das wäre dann also:
Currentdb.Execute
"INSERT INTO " & rezarc & "SELECT * FROM " & rez & ";", dbFailOnError

RunSQL lasse ich nur, wenn ich dem User ohne Mehrarbeit die
billige Show mit den Fortschrittsbalken in der Statusleiste bieten will. ;-)

[Steven Prohaska]

Danke Karl und Michael !

Post by Karl Donaubauer
Es fehlt ein Leerzeichen bei: " SELECT "

Ja das war's - ein schnödes Leerzeichen hatte ich zu wenig.
Wir im Schwabenländle sind halt ein sparsames Volk ;-)

Post by Karl Donaubauer
BTW
Ich nehme zum Testen wegen der Meldungen auch gerne RunSQL.
Im Ernstfall dann aber eher Execute, weil's schneller ist, man die
Access-Meldungen nicht wegschalten muss und das Abbrechen
bei Fehler sicherer ist. Das 1. rez kannst du auch noch wegkürzen.
Currentdb.Execute
"INSERT INTO " & rezarc & "SELECT * FROM " & rez & ";", dbFailOnError
RunSQL lasse ich nur, wenn ich dem User ohne Mehrarbeit die
billige Show mit den Fortschrittsbalken in der Statusleiste bieten will. ;-)

Danke für den Hinweis, daß Execute schneller läuft.
Werde auf Execute umsteigen, da muß der User eben ohne diese
spannende Unterhaltung auskommen ;-)

Gruß - Steven