Keine Fehlermeldung bei asynchronem Aufruf

[iGoA]

Moin!

Mich plagt ein Phänomen. Wenn ich ein TADOQuery asynchron öffne, werden sämtliche Fehlermeldungen verschluckt und ich erhalte niemals Feedback, ob die Abfrage noch läuft oder gescheitert ist.
Hier mein Code:

Code:

  
    ...
    query.ExecuteOptions := [eoAsyncExecute,eoAsyncFetch,eoAsyncFetchNonBlocking];

    query.tag := 0; // sollte onFetchComplete auf 1 gesetzt werden
    query.Open;
    while (query.Tag = 0) do begin
        sleep(30);
        self.step; // hier gibt´s eine "Ich tue was"-Animation
    end;
    ...

In der While-Schleife wird eine Animation abgespielt, um dem user zu zeigen, dass das Programm gerade beschäftigt ist (darin auch ein application.processmessages). Wird das Ereignis onFetchComplete ausgelöst, wird tag auf 1 gesetzt und die Schleife bricht ab. Das funktioniert alles top, solange die Abfrage keine Fehler erzeugt. Die Schleife läuft aber unendlich weiter, wenn ein Fehler auftritt, das Programm auf keine Weise davon etwas mitbekommt und somit tag nie auf 1 gesetzt wird.

Ideen?

EDIT: Arbeite übrigens mit Delphi 2009

[Sir Rufo]

Es gibt dort eine Eigenschaft, wo man den aktuellen Status der Abfrage Auslesen kann.

Habe aber gerade keine Möglichkeit zum Schauen

Da kann man sich auch das mit dem Tag setzen schenken ;)

Das da meine ich http://docs.embarcadero.com/products...Set_State.html

[iGoA]

Danke, das ist ein guter Tipp nebenbei. Jedoch bleibt state auch bei Fehlern immer auf "fsOpening" kleben, so dass mein Problem leider weiterhin besteht.

[iGoA]

Sonst keine Ideen?

[iGoA]

Ich bin normalerweise nicht so nervig, aber ich push das Thema hiermit nochmal, weil ich dazu im Netz immernoch keine nützlichen Hinweise gefunden habe. Und das wundert mich, weil ich mir nicht vorstellen kann, dass ich der erste bin, der dieses Problem hat.
Also sorry, für´s nerven, aber vielleicht stöst so noch jemand auf diesen Thread der dazu was sagen kann.

[Sir Rufo]

Da gibt es wohl keine Lösung, wenn du weiterhin mit asynchron arbeiten möchtest.

Ein andere Ansatz wäre, die Abfrage in einen Thread auszulagern. Da wird dann nicht asynchron abgefragt und trotzdem friert deine Oberfläche nicht ein.

[iGoA]

So herum hatte ich es auch schon probiert, aber wie Du schon sagst, kann man dabei die Oberfläche nicht aktualisieren. Das ist alles sehr schade, denn die ganze Aktion sollte ja gerade dazu dienen, dem User zu zeigen, dass das Programm noch arbeitet (es werden teils sehr aufwändige und langsame Abfragen gemacht).
Aber trotzdem vielen Dank!

[gmc616]

Delphi-Quellcode:

query.Open

wirft keine Exception wenn die Anfrage fehlerhaft ist?

[iGoA]

Genau das ist das Problem. Normalerweise wird eine Exception geworfen, aber eben leider nicht, wenn die Abfrage asynchron geöffnet wird. Wahrscheinlich verläuft sich die Exception dann irgendwo im Nebenthread und landet im Nirvana.

[gmc616]

Ich würde die While-Schleife anders gestalten.

Delphi-Quellcode:

While (not (Query.EOF)) do

Query.EOF sollte TRUE sein, wenn die Anfrage fehlerhaft ist.
Ob das allerdings bei einem asynchronem Aufruf funktioniert, weiß ich nicht.

Dann gibt es da noch die Eigenschaft TAdoQuery.Prepared. Evtl. kann man damit etwas anfangen?

Mehr fällt mir i.M. auch nicht ein. Bleibt nur noch die Lösung von Sir Rufo.

[Sir Rufo]

Es gibt da noch eine Möglichkeit:

Lass die Abfrage vorab vom Server prüfen!

Bei MSSQL und MySQL geht das auf jeden Fall, bei Oracle müsste es ähnlich wie bei MySQL gehen mit

Code:

PREPARE

Wenn das dann funktioniert, kannst du es getrost abschicken.

Wenn du direkten Einfluss auf die Erzeugung des Select hast, dann kannst du auch wie folgt im Vorfeld prüfen lassen
Originalabfrage:

Code:

select fielda, fieldb
from foo
where fielda = 1 or fieldb = 4

Prüfabfrage

Code:

select fielda, fieldb
from foo
where 1=0 and ( fielda = 1 or fieldb = 4 )

Geht aber nur dann wirklich gut, wenn die Erstellung der Abfrage-Syntax weitesgehend in deiner Hand liegt

[iGoA]

Das mit EOF und Prepared werde ich mal ausprobieren. Danke!

EDIT: @Sir Rufo:
Gerade erst Deinen post gesehen. Das ist ein cooler Trick. Auch dafür wieder danke!

[Sir Rufo]

Das mit dem EOF ist aber kein Hinweis auf einen Fehler.

Wenn eine leere Datenmenge zurückgeliefert wird, dann ist EOF auch True.
Weiterhin macht der Wert EOF erst dann einen Sinn, wenn die Abfrage geöffnet wurde.
In einem Fehlerfall (über ASync) ist die aber im Status dsOpening und da ist der Wert in EOF absolut unbrauchbar.

EOF bedeutet hier ja am Ende der Datenmenge, aber welcher ... die kommt ja evtl. erst noch.

Da fällt mir doch eine viel bessere Möglichkeit zum Testen der Abfrage ein:

Code:

select * from (
{ Code der zu prüfenden Abfrage }
) AS T
where 1 = 0

[iGoA]

Wird immer besser! Bin leider noch nicht zum Testen gekommen, weil ich gerade wieder an einer anderen Ecke programmieren muss.