Announcement

**Andreas Kosch** · 01.12.1999, 14:13

Hallo,

in der letzten Ausgabe von DER ENTWICKLER habe ich eine Alternative zum SQL-Monitor vorgestellt, mit deren Hilfe die Besitzer der Professional-Version von Delphi die gleichen Untersuchungs-Ergebnisse erhalten. Das Beispielprogramm installiert dazu einen BDE-Callback und kann �ber http://www.entwickler.com/entwickler/codes/de699/delphi/SQLAnweisungen.zip heruntergeladen werden.

Die Frage ist, wof�r die 10 Sekunden Zeit ben�tigt werden. F�r das Zusammenstellen des Ergebnisses auf dem InterBase, oder f�r das �bertragen aller (!) Datens�tze zum Client.

Bei einer LIKE-Abfrage �ber einen Parameterwert (dessen Inhalt beim Prepare nicht feststeht) wird der InterBase sicherlich keinen Index verwenden (als Parameter k�nnte nur % �bergeben werden, so dass ein Index nicht hilfreich ist). Beim Aufruf aus ISQL heraus wird bestimmt kein Parameter, sondern ein Wert angegeben (so das der Optimizer das % an f�hrender Stelle sofort ausschliessen kann).

Ich daher folgende Alternativen ausprobieren: 
1. Der TQuery-Instanz einen "fertigen" SQL-Text (ohne Parameter) zuweisen und danach �ffnen. 
2. Oder besser: Die SELECT-Abfrage in eine Stored Procedure legen, die als SELECT-Prozedur die Ergebnismenge zur�ckliefert. Innerhalb dieser Stored Procedure sollte alles das m�glich sein, was auch via ISQL abgesetzt werden kann.
&#10

**Kai M�ller** · 01.12.1999, 16:08

Hallo Andreas,

mit anderen Worten:

Interbase macht das Prepare schon, bevor es meine Parameterinhalte kennt?! Du hast richtig getippt. In ISQL arbeite ich nat�rlich mit festen Parameter-Werten.

Kann ich das Prepare nicht nochmals NACH der Parameterzuweisung erzwingen?

�brigens hole ich ja nur ganz wenige Datens�tze (1...10) in der Ergebnismenge zur�ck. Eine �hnliche Abfrage �ber TQuery mit vollqualifiziertem Key (KEIN Like, sondern =) l�uft ja sehr schnell (< 1s). Das �bertragen sollte also nicht das Zeitproblem verursachen

Deine Alternative 1 gef�llt mir insofern nicht nicht, da ich so alle evtl eingegebenen Sonderzeichen in den Parametern (', ") abfangen mu�, die sonst CHaos in meiner Query anrichten.

Alternative 2: Kann ich denn aus einer Stored Procedure mit einem SELECT lesen? Und was wird mit den Parametern f�r die Suchbegriffe, die ich dorthin �bergebe? F�hren die nicht zum gleichen Problem wie die direkte Abfrage?

Auf jeden Fall werde ich mal Dein Tool ausprobieren.

Danke + Gru� Ka

**Andreas Kosch** · 02.12.1999, 06:43

Hallo Kai,

beim Prepare wird exakt die Zeichenkette (SELECT-Anweisung) an den InterBase �bergeben, der auch in TQuery.SQL eingetragen ist. Nur der Parameter-Platzhalter wird durch das im SQL-Standard vorgesehene Fragezeichen ersetzt. Somit "kennt" der InterBase nur die Anweisung, aber nicht die Parameter. Solange sich die SQL-Anweisung nicht �ndert, k�nnen verschiedene SELECTs mit verschiedenen Parametern aufgerufen werden, ohne das jedesmal ein neues Prepare (mit Optimizer-Lauf des InterBase) notwendig wird.

Zur Frage 2: Der InterBase kennt SELECT-Prozeduren, die ganz normal �ber eine TQuery abgefragt werden k�nnen (SELECT * FROM prozedurename). Anstelle eines Tabellen- oder View-Namen wird nur der Name der Stored Procedure �bergeben. Allerdings muss diese Stored Procedure den Regeln f�r SELECT-Prozeduren entsprechen (siehe InterBase-Handb�cher) und SUSPEND f�r jeden Datensatz in der Treffermenge aufrufen. Wenn mit ISQL der Optimizer �berstimmt werden kann (Query-Plan), kann diese Anweisung auch direkt in der Stored Procedure verwendet werden (d.h. da alles auf dem InterBase Server abl�uft, kann TQuery/VCL keine "Vetos" gegen bestimmte Aufrufe einlegen).

P.S: Der InterBase unterst�tzt auch die Abfrage mit STARTING WITH - und bei dieser Joker-Abfrage wird immer ein INDEX verwendet. Eine Gegen�berstellung der Alternativen findet sich in meinem Buch Client/Server Datenbankentwicklung mit Delphi auf den Seiten 263 und 264.
&#10

**Kai M�ller** · 03.12.1999, 08:17

Hallo Andreas (und alle anderen),

ich mache es jetzt so:
Wenn im Suchstring keine Jokerzeichen (%, ...) sind, generiere ich die Abfrage mit STARTING WITH,
wenn Jokerzeichen im Suchbegriff eingegeben wurden, kommt ein LIKE in die Abfrage. Im zweiten Fall mu� der Benutzer dann eben mit einer l�ngeren Antwortzeit rechnen, bekommt aber auch ein Ergebnis.
Ich denke, so ist es am schnellsten und am benutzerfreundlichsten.

Kai

**Andreas Kosch** · 03.12.1999, 09:55

Hallo Kai,

beim Einsatz von STARTING WITH wird implizit vom InterBase ein %-Joker (logisch) angeh�ngt, da der Server alle die Datens�tze zur�ckliefert, die mit der �bergebenen Zeichenkette beginnen. Man muss also nicht extra ein % �bergeben

**Kai M�ller** · 03.12.1999, 11:08

Hallo Andreas,

ja klar - es ist sogar nach meinen Experimenten so, da� Du selber kein % anh�ngen DARFST, sonst liefert STARTING WITH keine Ergebnismenge.

Die Unterscheidung in meinem Programm treffe ich, weil der User ja auch auf die Idee kommen k�nnte (irgendeiner WIRD es tun!!), einen Joker irgendwo mitten im Suchwort zu platzieren,
z.B. '%Brenner' oder 'Model A_09'. Da versagt n�mlich STARTING WITH und mein LIKE kommt zum tragen :-)

Gru� Ka

**Andreas Tengicki** · 03.12.1999, 12:43

<ul>
<li> Like wird immer mit einem Fulltable-Scan bearbeitet so wei� ich wei�
<li> Machst Du ein explizietes Prepare bevor Du den Parameter zuweiset. Dann ist er meist etwas schneller
<pre>
mytable.prepare;
mytabe.parambyName('p').AsString = "tra%lala";
mytable.open;
</pre>
</ul&gt

Announcement

Optimierter Select funktioniert nicht in Delphi

Optimierter Select funktioniert nicht in Delphi

Comment

Comment

Comment

Comment

Comment

Comment

Comment