Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi DBGO-Komponenten mit Access: ADOQuery funktioniert nicht (https://www.delphipraxis.net/130811-dbgo-komponenten-mit-access-adoquery-funktioniert-nicht.html)

Cogito 13. Mär 2009 15:59

Datenbank: Access • Version: 2000 • Zugriff über: ADO

DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Hallo zusammen,

ich versuche eigentlich was ganz simples, was mit den CoreLab Komponenten immer funktioniert hat, nämlich eine einfache Delete-Abfrage auszuführen.
Ich nehme also eine ADOQuery-Komponente und weise der SQL-Eigenschaft folgenden Text zu:

SQL-Code:
DELETE FROM Translation WHERE (KeyField = :key)
Dann bestücke ich zur Laufzeit den Parameter key mit ...

Delphi-Quellcode:
 ReportingDM.MSSQL_TranslationDelete.Parameters.ParamByName('key').Value := schluessel;
...führe das ganze dann mittels ExecSQL aus und ernte prompt eine Fehlermeldung: "Syntaxfehler in FROM Klausel".
Wie gesagt, bei Corelab hat das funktioniert, war aber auch der SQL Server, jetzt ist Access die zugrundeliegende DB.
Kann mir hier jemand weiterhelfen?

mkinzler 13. Mär 2009 16:02

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Access wird, wie die meisten DBMS, keine Parameter für Datenbankobjekte ( Tabellennamen, Feldnamen, ...) unterstützen

Bernhard Geyer 13. Mär 2009 16:09

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Welcher Feldtyp hat Key? Evtl. auch ein Schlüsselwort in Access?
Was passiert wenn du die Query direkt in Access ausführtst?

Cogito 13. Mär 2009 16:37

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Zitat:

Zitat von Bernhard Geyer
Welcher Feldtyp hat Key? Evtl. auch ein Schlüsselwort in Access?
Was passiert wenn du die Query direkt in Access ausführtst?

Dann erkennt Access den Wert :key als Parameter, fragt nach dem Wert und führt die Abfrage aus.

Zitat:

Zitat von mkinzler
Access wird, wie die meisten DBMS, keine Parameter für Datenbankobjekte ( Tabellennamen, Feldnamen, ...) unterstützen

Ich schätze du wirst wohl leider recht haben. :wall:

Welche Alternative gäbe es denn dann (ausser alles im Quellcode auszuführen) ?

shmia 13. Mär 2009 16:59

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Liste der Anhänge anzeigen (Anzahl: 1)
Wahrscheinlich ist "Translation" ein reserviertes Wort von Access.
Man darf bestimmte Feld-, Tabellen und Viewnamen einfach nicht benützten!

GOLDENE REGEL für alle Datenbankprogrammierer:
Alle Namen (Bezeichner) kontrollieren, ob es nicht ein reserviertes Wort ist.
Ich nehme dazu immer ein Tool; siehe Anhang.

Cogito 14. Mär 2009 09:55

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Zitat:

Zitat von shmia
Wahrscheinlich ist "Translation" ein reserviertes Wort von Access.
Man darf bestimmte Feld-, Tabellen und Viewnamen einfach nicht benützten!

GOLDENE REGEL für alle Datenbankprogrammierer:
Alle Namen (Bezeichner) kontrollieren, ob es nicht ein reserviertes Wort ist.
Ich nehme dazu immer ein Tool; siehe Anhang.

Das war in der Tat das Problem. Darauf wäre ich nie gekommen, weil SQL Server vermutlich hinsichtlich der Benamung nicht so restriktiv sind wie Access.
Wo gibt es denn dieses Tool ?

Bernhard Geyer 14. Mär 2009 10:27

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Zitat:

Zitat von Cogito
..., weil SQL Server vermutlich hinsichtlich der Benamung nicht so restriktiv sind wie Access. ...

Ist er genauso. Hat nur andere Schlüsselwörter. Und je nach DBMS kann man den Feld/Tabellennamen mittels [...] oder '...' kennzeichnen das dies nicht mehr stört.

shmia 16. Mär 2009 12:55

Re: DBGO-Komponenten mit Access: ADOQuery funktioniert nicht
 
Zitat:

Zitat von Cogito
Wo gibt es denn dieses Tool ?

Hier: http://www.delphipraxis.net/internal...ct.php?t=19596


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:33 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz