DBX meldet Syntaxfehler wo keine sind

[Der schöne Günther]

Hallo.

Ich kenne mich mit Datenbanken in der Praxis nur sehr rudimentär aus. Ich weiß noch nicht einmal, ob ich die Felder "ergänzende Angaben" richtig asugefüllt habe. Mein Problem ist folgendes: Ich möchte mit Delphi einfach nur aus einer SQLite-DB mittels SELECT eine Ergebnismenge bekommen. Bislang ging das gut. Eine etwas komplexere Abfrage (Vereinigung zweier Abfragen mit Unterabfrage) scheitert nun - Angeblich sogar Syntaxfehler.

Normalerweise sucht man die Schuld bei sich selbst, nur bekommen andere Tools die exakt gleiche Abfrage auf der exakt gleichen Datenbank es ohne Probleme hin (SQLite Expert Personal oder SQLite Database Browser 2.0)!

Habe ich in Delphi irgendeine Einstellung vergessen?

Die Verbindung vom Typ

Delphi-Quellcode:

TSQLConnection

lege ich folgendermaßen an:

Delphi-Quellcode:

   sqlConnection := TSQLConnection.Create(nil);
   sqlConnection.Connected := False;
   sqlConnection.DriverName := 'Sqlite';

   sqlConnection.Params.Values['Database'] := startupFile;
   sqlConnection.Params.Values['FailIfMissing'] := 'True';

, abholen tue ich mir die Werte über

Delphi-Quellcode:

   query := '[...]';

   sqlConnection.Execute(
      query,
      nil,
      result
   );

   result.First();
   while not result.Eof do begin
      [...]
      result.Next();
   end;

Mache ich hier schon etwas falsch? Irgendeine "Aktiviere dies, wenn es etwas komplexer wird"-Einstellung vergessen? Ich habe auch die sqlite.dll gegen die sqlite.dll des "SQLite Expert Personal"-Tools ausgetauscht, das hat auch nichts gebracht.

[baumina]

Evtl. liegt es daran, dass TSQLConnection nur unidirektional zugreifen kann, dein select aber mehr bräuchte.

[Der schöne Günther]

Ich nix verstehen :(

Meine Abfrage vereint zwei SELECT-statements mittels UNION, erstere hat eine Unterabfrage die sich auf die Ergebnismenge der äußeren bezieht. Das ist neu, ganz einfache SELECT-Abfragen gingen bislang. Gut möglich, dass der Typ

Delphi-Quellcode:

TSQLConnection

nicht mehr reicht und jetzt etwas neues her muss. Nur was?

[baumina]

Leider bietet Delphi von sich aus nur diesen unbrauchbaren unidirektionalen (kann nur in eine Richtung lesen) Zugriff an. Wenn der select korrekt ist und andere selects funktionieren, liegt es sicherlich daran. Vernünftigen Datenbankzugriff bekommst du nur über Drittanbieter, ich hatte zuerst ZEOS danach hatte ich mich für UniDAC entschieden.

Soviel ich weiß können XE4-Version-Besitzer auf die kostenlose FireDAC zugreifen, welche man sich glaube zuvor runterladen muss.

[Uwe Raabe]

Probier es doch mit FireDAC.

[Der schöne Günther]

Ich wollte eigentlich nichts weiter als eine lokale Konfiguration aus einem paar KB großen SQLite-File einlesen.

Muss ich mir jetzt wieder irgendwelche Enterprise-Lösungen herunterladen und installieren nur um ein halbes Dutzend Zeilen aus einer SQLite-DB zu lesen? :oops:

[baumina]

Du kannst auch versuchen den select "einfacher" zu formulieren, daraus mehrere selects zu machen und die "Union"-Syntax programmtechnisch lösen.

[jobo]

Bei einfachen Treibern oder Backend Engines hilft oft:
- Alias für Tables und Columns prüfen und konsistent einsetzen
(ich meine mich dunkel zu erinnern, dass es hier bei sqLite sogar ne besondere Besonderheit gab..)
- Bei Union mindestens im ersten SQL auf Spaltenalias bei "berechneten " Feldern achten
- ggF helfende, äußere Selects um die inneren, komplexen.

Spezialisierte Thirdparty Tools verhalten sich idR schlauer als stanard Komponenten. Ein fehlender oder kryptischer (weil aus der Feld-Oeration selbst gebildet~Spalte nennt sich dann wie die sie erzeugende Funktion) Feldalias kommt ggF. im Spezialtool harmlos rüber, ist aber nicht gut für DBX, ...

Tja und wichtig wäre ggF das Statement selbst hier zu posten.

[Der schöne Günther]

Spalten mit bösen Namen sind ein guter Hinweis. :thumb:

Aber daran lag es nicht: Die Syntaxfehler habe ich in den Griff bekommen, er kam mit den Tab-Charakteren die noch im (formatierten) String gesteckt haben nicht zurecht. In der Exception wurden die nicht angezeigt. Das Problem liegt jetzt weiter eindeutig darin, dass er in der inneren Abfrage nichts von der äußeren weiß und hier mit Exception rausfliegt.

Mit FireDac habe ich jetzt ein paar Minuten probiert, bekomme es aber auf die Schnelle nicht hin. Eine Exe-Größe die dann auch auf 27MB anschwillt hat dabei auch einen gewissen Unterhaltungswert :-D
Insgesamt ist mir meine Zeit für so etwas auch zu schade, ich fummele es mir dann lieber über Applikationslogik zurecht.

Für benutzerdefinierte SQLite-Geschichten die unter XE4 noch funktionieren gehe ich euch dann wohl ein anderes mal auf den Senkel. Danke bis hierhin.

[jobo]

Schnellgooglen ergab, das sqlite scheinbar zwingend SpaltenAlias bei brechneten Spalten braucht, aber die Info ist ohne Gewehr, HandinsFeuer usw. irgendwas war da jedenfalls...
Du machst es ja eh anders.

[Der schöne Günther]

Mich an Datenbanken zu lassen ist sowieso wie einen Schimpansen ein atomar bewaffnetes Kampfflugzeug fliegen zu lassen, aber solange ich darunter nichts falsch verstehe, hätte ich behauptet, keine Spalten dynamisch zu erzeugen:

Code:

SELECT [spaltenmenge] FROM (tab1 JOIN tab2 ON [...])
WHERE
NOT EXISTS
   (SELECT [...])

UNION

SELECT [spaltenmenge] FROM
   tabx JOIN taby ON [...]
;

So sah es aus, zwei Freeware-Tools bekamen es problemlos hin, mein Delphi-Duo aus

Delphi-Quellcode:

TSQLConnection

und

Delphi-Quellcode:

TDataSet

nicht.

[jobo]

Ne, das sieht schon ok aus. Es sei denn in Wirklichkeit ersetzt Du [Spaltenmenge] durch ein '*'. Keine Ahnung wie sqLite/dbx das mit Union schluckt.
Wie sieht es denn aus mit

Delphi-Quellcode:

Select [Spaltenmenge] from 
(
Voriges Union Statement
)

?

[Der schöne Günther]

Nein, die Spalten sind bei beiden Abfragen die gleichen. Oder habe ich was falsch verstanden?

[Uwe Raabe]

Zitat:

Zitat von Der schöne Günther (Beitrag 1219578)

Muss ich mir jetzt wieder irgendwelche Enterprise-Lösungen herunterladen und installieren nur um ein halbes Dutzend Zeilen aus einer SQLite-DB zu lesen? :oops:

Dein Profil sagt aber doch XE4 Enterprise. Daher bin ich davon ausgegangen, daß FireDAC bei dir installiert ist.

FireDAC ist erstmal nichts weiter als eine Alternative zu dbExpress. Natürlich muss man bei jeder verwendeten Technologie mit einem Lernaufwand rechnen. Nach meiner Erfahrung ist der bei FireDAC aber geringer als bei dbExpress.

[Der schöne Günther]

Ja, für die Installation musste ich mir zum Glück doch kein Bein ausreißen. Auf Dauer lohnt es sich bestimmt, sich in das Teil einzuarbeiten. Nur im Moment lohnt es sich für mich nicht, das dürfte für die nächsten Monate meine einzige Berührung mit Datenbanken gewesen sein :-)

Ich habe vielleicht auch etwas ungehalten reagiert da ich mit der Zeit etwas aggressiv wurde, so einen Kleinkram nicht mit Bordmitteln hinzubekommen. Es in Anwendungslogik zusammenzubasteln hat keine 120 Sekunden gedauert, aber unschön ist es trotzdem.

[nahpets]

Hallo,

zeig' uns doch bitte mal das SQL-Statement, eventuell sind ja nur ein paar Besonderheiten vorhanden, die nur beim Absenden des SQL aus Delphi heraus zu beachten sind (QuotedStr oder sowas...).