Hallo ,

ich habe so ein interessantes Problem. Ich verwende Bind Variablen in Delphi und auf Datanbankseite wird Database Link (@dblink) verwendet um aus einer Tabelle Daten geholt zu werden. Wenn ich SQL SELECT-Abfrage so schicke , es ist schnell :

markieren

Code:

 
SELECT
 DLGH_START_D Datum,
 TRUNC((d.DLGH_ENDE_D - d.DLGH_START_D) * 24 * 60)||' Min '||
 TRUNC(MOD(((d.DLGH_ENDE_D - d.DLGH_START_D) * 24 * 3600), 60))||' Sek' Dauer
FROM
  dialoghistory d
WHERE
 d.DLGH_PARAMETER_C = 'Name of Parameter' AND <--
 d.dlgh_funktion_c = 'SQLS' AND
 d.DLGH_START_D > '01.02.2020' <--
order by 1

aber diese SQL Abfrage mit Bind Variablen dauert ewig:

markieren

Code:

SELECT
 DLGH_START_D Datum,
 TRUNC((d.DLGH_ENDE_D - d.DLGH_START_D) * 24 * 60)||' Min '||
 TRUNC(MOD(((d.DLGH_ENDE_D - d.DLGH_START_D) * 24 * 3600), 60))||' Sek' Dauer
FROM
  dialoghistory d
WHERE
 d.DLGH_PARAMETER_C = :B_Name AND <--
 d.dlgh_funktion_c = 'SQLS' AND
 d.DLGH_START_D > :Datum   <--
order by 1

Delphi Code bereinigt:

markieren

Code:

qry := TFDQuery.CreateSQL(Application, sSqlText_.Text);
    with qry do begin
    ...
     Param.AsString := value; //Hier die Wert von Bind Variable setzen
    ...
    Open; //Hier wird lange hängen geblieben ~ 1 Stunde . ohne Bind Variablen 1 Sekunde

Es liegt vermutlich an dblink, aber genau was das ist und wie ich es umgehen kann, keine Idee

Das muss schneller gehen. Da gibt's doch auch was mit Prepare.
Das reicht normalerweise einmal auszuführen.
Hast du die Möglichkeit den Zugriffs-Plan der DB in beiden Fällen zu vergleichen?

Zitat von Nikolozi:

Delphi Code bereinigt:

Und jetzt nochmal nicht ganz so bereinigt - aber wirklich echter Code!

Bitte ohne "with". Du tust dir keinen gefallen damit.
Ich hoffe, den zweiten Parameter übergibst du als "AsDateTime".

Benutzt du für den DBLink einen ODBC-Treiber oder arbeitest du native?
Ich habe schonmal gelesen, dass manche ODBC-Treiber mit parametrisierten SQL-Anweisungen Probleme haben.

Moin...

Zitat:

Ich verwende Bind Variablen in Delphi

Begriffsdefinion: meinst du damit Parameter?

Wie viele Datensätze sind in der Tabelle?

https://en.delphipraxis.net/topic/62...#comment-54473

...schau dir das mal an. Dmitry muss es wissen!

Soetwas ähnliches hatte ich auch mal.
Da hatte ich ein Parameter als falsche Variable übergeben.
Beispiel:
ParamByName( 'Integer' ).AsString := 'Test' Obwohl das Feld in der Datenbank ein Integer war!
Das hat Stunden gedauert.

Also ich bin bei @Jasocul mit dem DateTime Paramter

Wenn hier

markieren

Delphi-Quellcode:

 d.DLGH_PARAMETER_C = :B_Name AND
 d.dlgh_funktion_c = 'SQLS' AND
 d.DLGH_START_D > :Datum

einer der Parameter vom Typ nicht mit dem der entsprechenden Spalte in der DB übereinstimmt, wird (wenn Du Pech hast) die entsprechende Spalte der Tabelle für jeden Datensatz in den Typen des Parameters umgewandelt und dann verglichen und nicht einmal der Parameter in den Typ der Spalte und dann verglichen.
Und dann war's das mit der Nutzung des Index und schon wird die Laufzeit (schlimmstenfalls) astronomisch hoch.

Bei der schnelle Variante wird Dir der Zugriffs-Plan vermutlich verraten, welcher Index genutzt wird und bei der langsamen Variante steht da (sinngemäß) was von "full table scan".

Ich sehe im SQL keinen DBLink.
Falscher Variabentyp auf Delphiseite könnte schon sein.

DBLinks (bei Oracle) sind ein Thema für sich.
Miserable Geschwindigkeit kann daher rühren, dass der Optimizer sich nicht in der Lage sieht, die Abfrage remote (über Link) zu bewältigen und Daten ungefiltert aus dem DBLink saugt.

Das Verhalten müsste prüfbar sein, wenn man auf Client Code verzichtet und direkt per SQL Client arbeitet.

P.S.: Wie schon angedeutet, ein Paramter in der SQL Abfrage ist etwas anderes als eine Bind Variable in Oracle.