FB: Prepared Query mit In-Statement ?

[hoika]

Hallo,
ich habe eine Query, die wird 100mal ausgeführt.

Select Feld3 From Tab
Where
(Feld1=:Feld1) And
(Feld2 In :Feld2)

Feld1 ist Integer
Feld2 ein String oder String-Liste

Leider kann ich die Query nicht preparen wegen dem In.

Geht das irgendwie anders ??

[mkinzler]

Was steht den in dem Parameter Feld2?

[Delphi.Narium]

Warum geht das nicht?

Fehlermeldung?

Quelltext mit Parameterbefüllung und konkreten Beispieldaten?

[mkinzler]

IN unterstützt keine Parameter.

[Delphi.Narium]

Jain, so absolut stimmt das nicht.

Je Parameter darf nur ein Wert übergeben werden.

Dashier funktioniert:

Delphi-Quellcode:

  qry.Close;
  qry.SQL.Clear;
  qry.SQL.Add('select feld3 from tabelle where feld1 = :feld1 ');
  qry.SQL.Add('and feld2 in (:feld2) ');
  qry.Prepare;
  qry.Params[0].AsInteger := 1;
  qry.Params[1].AsString  := '''Feldinhalt''';
  qry.Open;
  ShowMessage(Format('%d',[qry.RecordCount]));
  qry.Close;

Dashier funktioniert ebenfalls:

Delphi-Quellcode:

  qry.Close;
  qry.SQL.Clear;
  qry.SQL.Add('select feld3 from tabelle where feld1 = :feld1 ');
  qry.SQL.Add('and feld2 in (:feld2a,:feld2b,:feld2c) ');
  qry.Prepare;
  qry.Params[0].AsInteger := 1;
  qry.Params[1].AsString  := '''FeldinhaltA''';
  qry.Params[2].AsString  := '''FeldinhaltB''';
  qry.Params[3].AsString  := '''FeldinhaltC''';
  qry.Open;
  ShowMessage(Format('%d',[qry.RecordCount]));
  qry.Close;

Dashier funktioniert jedoch nicht:

Delphi-Quellcode:

  qry.Close;
  qry.SQL.Clear;
  qry.SQL.Add('select feld3 from tabelle where feld1 = :feld1 ');
  qry.SQL.Add('and feld2 in (:feld2) ');
  qry.Prepare;
  qry.Params[0].AsInteger := 1;
  qry.Params[1].AsString  := '''FeldinhaltA'',''FeldinhaltB'',''FeldinhaltC''';
  qry.Open;
  ShowMessage(Format('%d',[qry.RecordCount]));
  qry.Close;

[hoika]

Hallo,
Fehlermeldung beim Prepare "Token ? unknown"

Feld2 ist eine variable Anzahl von Strings.

Ich habe hier IBExpert und IBDAC.

Das das Prepare nicht geht, ist ja bekannt, wie könnte man das denn lösen?
Ich möchte ungern X prepared Queries (pro Anzahl der Strings eine) bauen, sehe das aber als einzige Lösung.

[Delphi.Narium]

Token unknown lässt auf einen Syntaxfehler im SQL schließen, vermutlich ist das aber nur eine Teilmenge der Fehlermeldung.
Bitte mal das vollständige SQL und die vollständige Fehlermeldung. So ist das nur was für die

Ein Parameter = ein Wert.
Wenn ein Wert aus mehreren Zeichenfolgen besteht, geht das.

Wenn ein Parameter aber mehrere einzelne Werte enthält, die eigentlich separat ins IN sollen, dann geht das nicht.

Delphi-Quellcode:

qry.SQL.Text := 'select * from x where feld2 IN (:Parameter)';
qry.Params[0].AsString := 'Das ist jetzt mal etwas Text.';

funktioniert.
Das wird zu select * from x where feld2 IN ('Das ist jetzt mal etwas Text.') , wobei hier das IN auch durch ein = ersetzt werden könnte.

Delphi-Quellcode:

qry.SQL.Text := 'select * from x where feld2 IN (:P1,:P2,:P3,:P4,:P5,:P6)';
qry.Params[0].AsString := 'Das'
qry.Params[1].AsString := 'ist'
qry.Params[2].AsString := 'jetzt'
qry.Params[3].AsString := 'mal'
qry.Params[4].AsString := 'etwas'
qry.Params[5].AsString := 'Text.'

funktioniert, kann aber zu einem deutlich anderen Ergebnis, als die vorherige Variante, führen.

Delphi-Quellcode:

qry.SQL.Text := 'select * from x where feld2 IN (:Parameter)';
qry.Params[0].AsString := '''Das'',''ist'',''jetzt'',''mal'',''etwas'',''Text.''';

funktioniert eventuell technisch. Im IN steht aber nur ein Wert, nach dem gesucht werden soll, und nicht sechs Werte, wie der Aufbau des Parameters suggerieren könnte. Und wenn hier die Anzahl der ' nicht so ganz passt, könnte die daraus resultierende Fehlermeldung auch 'Token unknown' enthalten.

[Delphi.Narium]

Zitat von hoika:

Select Feld3 From Tab
Where
(Feld1=:Feld1) And
(Feld2 In :Feld2)

Das geht nicht, nur so:

SQL-Code:

Select Feld3 From Tab
Where 
  (Feld1=:Feld1) And
  (Feld2 In (:Feld2))

Die Klammern dürfen nicht Teil des Parameterinhaltes sein. Ist dem so, so ist "Token unknown" ein Teil der Fehlermeldung.

Vollständig dürfte sie in etwa

Zitat:

SQL Error: Dynamic SQL Error SQL error code = -104 Token unknown - line 1, column 35 ?. Error Code: -104. Invalid token The SQL: select id from tabbel where id in ?;

lauten.

Zitat von hoika:

Hallo,
der Fehler kommt bereits beim Prepare,
hat also nichts mit der Anzahl der später tatsächlichen Parameter zu tun.

FB macht das schon richtig so, dass es sagt, IN kann nicht prepared werden.

Doch, das hat mit den Parametern zu tuen. Die sind in Deinem Statement schlicht und einfach falsch und deshalb hat Prepare kein gültiges SQL, das es später mit Parametern versorgen kann.

Um Die Syntax für das Prepare zu prüfen, gehe ich zum Testen immer her und mache um die Parameter Hochkommata.

Also

SQL-Code:

Select Feld3 From Tab
Where 
  (Feld1=':Feld1') And
  (Feld2 In ':Feld2')

bei Deinem Statement. Das wird auch scheitern, da es ein ungültiges SQL ist. Die Klammern beim IN fehlen!!!
Parameter können nur Werte enthalten, aber nicht Teile des SQLs. Die Klammern sind aber Teile des SQLs.

SQL-Code:

Select Feld3 From Tab
Where 
  (Feld1=:Feld1) And
  (Feld2 :Feld2)

qry.params[0] := 'in (1,2,3)'; geht ja auch nicht oder gar

SQL-Code:

Select Feld3 From Tab
Where 
  (Feld1=:Feld1) And
  (:Feld2)

qry.params[0] := 'feld2 in (1,2,3)'; geht auch nicht.

[jobo]

"100 mal eine Query"

Klingt etwas nach der berühmten Whileschleife für Queries.

Häufig kann man das IN zu einem JOIN auflösen. Das hilft nicht unbedingt weiter, außer in einem speziellen Fall. Wenn nämliche die vielen IN Werte alle an einem oder wenigen "Parent" Werten einer übergeordneten Tabelle hängen.
Gegenanzeige wäre bspw. das in dem IN disjunkte Werte aus einer Suchmaske stecken.

Wenn also die Zahl 100 darauf hindeutet, das in dieser 100er Schleife eine Dimension oder Menge durchgearbeitet wird, die man auch insgesamt in eine "große" Query auflösen kann, wäre das eine mögliche Lösung, das IN fliegt dann idealer Weise raus.

Also Frage wäre: Gibt es zu den 100 Abfragen eine Master Query?
Und wenn ja, wie sieht die aus?

Handarbeitslösung:
Die IN Werte in eine (temporäre) User spezifische Tabelle eintragen und die jetzige Query dagegen joinen. Oder bei einer bekannten Maximalanzahl von IN Werten, z.B. 5, mit 5 verschiedenen Queries arbeiten und jeweils die Query starten, die dazu dieser Parameter Anzahl entspricht.
Oder den fixen Teil der Query in einen View packen und auf Parametrieung und Prepare der IN Anweisung verzichten (dann ist wenigsten der View fertig prepared).

[IBExpert]

Zitat von hoika:

Geht das irgendwie anders ??

Hängt ein wenig von der Datenmenge ab, geht aber immer auch anders (ich hab mal die params P genannt)

1. bei kleineren Datenmengen so

Code:

Select Feld3 From Tab
Where 
(Feld1=:P1) And
(:P2 containing ';'||Feld2||';' )

dabei musst du dann einfach deinen Parameter P2 als semikolon getrennte Liste mit führendem und abschliessendem
Semikolon als String übergeben, z.B. so

Code:

qry.Params[0].AsInteger := 123;
qry.Params[1].AsString := ';a;b;x;';

Das sollte klappen, ist aber von der Performance nur für kleine Datenmenge sinnvoll, weil es garantiert einen
Full Table Scan macht

2. Je nach Netzwerkspeed und Anzahl an Parametern sollte man die Vorteile von prepare nicht überschätzen
und einfach den kompletten SQL so wie du den brauchst mit konstanten im SQL Text übertragen , d.h.

Code:

Select Feld3 From Tab
Where 
(Feld1=123) And
(Feld2 in ('a','b','x') )

3. Die optimalere Lösungs ggf auch für große Datenmenge
Erstelle eine Global Temporary Table mit on commit delete rows wo nur mögliche Parameter
reinkommen, Index anlegen ggf nicht vergessen
und packe deine Parameter in die Tabelle

Code:

CREATE GLOBAL TEMPORARY TABLE BRPARRAY (
    VAL   VARCHAR(80) NOT NULL PRIMARY KEY
) ON COMMIT DELETE ROWS;
commit;
INSERT INTO BRPARRAY VALUES ('a');
INSERT INTO BRPARRAY VALUES ('b');
INSERT INTO BRPARRAY VALUES ('x');
--achtung hier kein commit, sonst ist wegen on commit delete rows die tabelle wieder leer

Select Feld3 From Tab
join brparray on brparray.val=tab.feld2 
Where 
(Feld1=123)

In der Global Temporary Table GTT siehst du immer nur die Daten deiner eigenen Connection.
Mit on commit delete rows ist die nach dem commit leer
Mit on commit preserve rows ist die auch nach dem commit noch gefüllt, dann ggf einfach
selber entscheiden wann gelöscht werden soll.


Wir nutzen GTT zB dafür, das beim Programmstart die Userrechte und Translations einmalig
ausgelesen werden und immer in den GTTs drin sind, man also bei jeder Abfrage zB PLZ
Werte entsprechend der eigenen Rechte da drin zu haben und jede Abfrage kann immer an
eine oder mehrere passende GTTs gejoint werden.