Operation bei geschlossener Datenmenge nicht ausführbar

[alzaimar]

Hoika, hier wäre ein 'Select count(*)' eine Performancebremse. Besser (weil es nur darum, geht, ob überhaupt etwas zurückgekommen ist):

Delphi-Quellcode:

If Not MyQuery.IsEmpty Then ...

[Nuclear-Ping]

Ups, garnicht mitgekriegt, dass hier noch wer geantwortet hat. Sorry. ^^

Problem ist wieder aufgetaucht, diesmal aber auf der Testmaschine im Büro (... mit dem geänderten RecordCount) ... :wall: ... Ich kapiers nicht ... Vorallem wenn du dazu nen Projektleiter am Ohr hast, der erklärt haben will, warum das aufeinmal nicht mehr geht. :oops:

Ich verbau mal noch eure anderen Vorschläge (bis auf Select count(*) ^^) und dann mal schauen.

[edit]
@hoika: try/except war drum, hab ich nur auskommentiert, weil vorher eine eigene Meldung kam wie

Code:

----------------
Fehler bei SQL Abfrage:
<leer>

SQL:
SELECT * FROM SendingSchedule ...

---- [ OK ] ----

Nun kommt stattdessen die Meldung mit der geschlossenen Datenmenge.
[/edit]

[nochmal edit]
@samson:

Delphi-Quellcode:

If (not Query.BOF) and (not Query.EOF) then
  ...

Versuch das grad zu verstehen ... then was? Wenn ich das unter das Open packe, ergibts FALSE, weil's wahrscheinlich BOF && !EOF ist. Kapier das nicht. ^^
[/nochmal edit]

[mikhal]

Mach aus

Delphi-Quellcode:

If (not Query.BOF) and (not Query.EOF) then

mal

Delphi-Quellcode:

If not Query.IsEmpty then

, macht das Gleiche.

Grüße
Mikhal

[Nuclear-Ping]

Ok. Hab das jetzt so gemacht:

Delphi-Quellcode:

Open;
RecCnt := RecordCount;
if (RecCnt > 0) and (not IsEmpty) and Active then
  AssignSendingScheduleItems (List, AdsQuery, RecCnt);
Close;

... mal schauen, ob's immernoch knallt.

[hoika]

Hallo,

und wieder kein try finally ...


Heiko

[mikhal]

Delphi-Quellcode:

(RecCnt > 0)

ist das Gleiche wie

Delphi-Quellcode:

(not IsEmpty)

Grüße
Mikhal

[DeddyH]

Klingt irgendwie logisch ;)

[Union]

Ich würde folgendes versuchen:

• 1. AdsQuery.Sequenced := True;
  2. Processmessages in der Schleife durch Update der benötigten Komponenten ersetzen
  3. Die ganze Progress-Geschichte über einen Callback aufrufen lassen und nicht in die Schleifen integrieren

und dann prüfe mal, ob der Fehler beim ersten Durchlauf der while Schleife auftritt oder erst bei einem der folgenden (a > 0).

Des weiteren sehe ich solche Bemerkungen wie "try deaktiviert zur Fehlernachverfolgung". Bau doch mal MadExcept oder EurekaLog ein. Dann kannst Du auch vom Kunden qualifizierte Fehlerberichte erhalten, evtl. sogar automatisch per E-Mail. Und die mehrfachen with machen ein vernünftiges Debugging auch nicht gerade zum Kinderspiel.

[Nuclear-Ping]

Zitat:

Zitat von Union

Ich würde folgendes versuchen:

• 1. AdsQuery.Sequenced := True;
  2. Processmessages in der Schleife durch Update der benötigten Komponenten ersetzen
  3. Die ganze Progress-Geschichte über einen Callback aufrufen lassen und nicht in die Schleifen integrieren

und dann prüfe mal, ob der Fehler beim ersten Durchlauf der while Schleife auftritt oder erst bei einem der folgenden (a > 0).

Des weiteren sehe ich solche Bemerkungen wie "try deaktiviert zur Fehlernachverfolgung". Bau doch mal MadExcept oder EurekaLog ein. Dann kannst Du auch vom Kunden qualifizierte Fehlerberichte erhalten, evtl. sogar automatisch per E-Mail. Und die mehrfachen with machen ein vernünftiges Debugging auch nicht gerade zum Kinderspiel.

Hm, dass die ProcessMessages da drin das Problem verursachen können kann auch sein. Werd ich als nächstes versuchen, wenn das immernoch auftritt. Danke für den Hinweis! :)

Und wie schon gesagt: Das ist kein Fehler der immer auftritt, sondern nur manchmal, bei Vollmond oder was weiß ich. Ich kann ihn hier nichtmal reproduzieren.

Bzgl. Fehlerreporting benutze ich bereits von JEDI die Exception-Dialoge. Sieht man ja auch im ersten Post. Ich hab den Try-Except-Block da nur auskommentiert, weil vorher eine nichtssagende Fehlermeldung kam.

[Nuclear-Ping]

[edit]
Schwachsinn ^^
[/edit]