ADOQuery und Result

[Cosamia]

Liefert mir die ADOQuery ein Ergeignis, wenn die AdoQuery einen SQL.TEXT erfolgreich ausgeführt hat?

[mkinzler]

Eher wenn nicht

[shmia]

Nein, es gibt eine Exception, wenn ein Problem aufgetreten ist.
Wenn du UPDATE, INSERT oder DELETE - Anweisungen absendest, dann sollte man keine TAdoQuery sondern TAdoCommand verwenden.
(habe da zwischen den Zeilen gelesen, dass du keine normalen SELECT-Anweisungen ausführen möchtest)

TAdoCommand.Execute ist mehrfach überladen und liefert in einigen Varianten die Anzahl der betroffenen Datensätze zurück.

[Cosamia]

Ich habe das Thema, dass ich eine Query mit einem SQL Statement befülle, und hinterher per Rave ausdrucke.

Jetzt stellt sich das Problem, dass ich nach dem Query.open das Ravemodul öffne, welches aber wohl schneller ist, als Query mit dem Ausführen des Statements.

Ein Delay einbauen, halte ich für Pfusch, oder?

[Cosamia]

Der Code sieht so aus:

Delphi-Quellcode:

 {AdoQuery mit allen Werten aus tempdruck füllen}
    adoquerydruck.sql.Clear;
    adoquerydruck.sql.text := 'SELECT * FROM tempdruck';  // Hier wird die Query für Rave befüllt.
    adoquerydruck.Open;




    {Alle Datensätze  die aktiv sind im Grid anzeigen}
    adoquery1.Active := false;
    adoquery1.sql.Clear;
    adoquery1.sql.text := 'SELECT * FROM best WHERE active = TRUE';
    adoquery1.Open;
    adoquery1.First;

    
    {Rave Formular aufrufen}
    RvProject1.Open;
    RvProject1.Execute;

[shmia]

Zitat:

Zitat von Cosamia

Jetzt stellt sich das Problem, dass ich nach dem Query.open das Ravemodul öffne, welches aber wohl schneller ist, als Query mit dem Ausführen des Statements.

Das kann nicht sein. Das Programm kann [TADOQuery.]Open erst verlassen, wenn alle Daten gelesen sind.
Bei CursorLocation = clUseServer werden zwar Daten nachgeladen während man durch die Datenmenge geht, das macht aber programmiertechnisch keinen Unterschied.
adoquery1.First kannst du weglassen; nach einem ausgeführten Open steht der aktuelle Datensatz immer auf dem 1. Satz.

[Cosamia]

Dann steckt das Problem woanders. Wenn ich mit mit F7 durch die einzelnen Schritte gehe, bringt Rave das gewünschte Ergebnis.

Beim normalen Programmdurchlauf leider nicht.

[shmia]

Zitat:

Zitat von Cosamia

Dann steckt das Problem woanders. Wenn ich mit mit F7 durch die einzelnen Schritte gehe, bringt Rave das gewünschte Ergebnis.
Beim normalen Programmdurchlauf leider nicht.

Dann setz doch mal einen sleep(5000) an strategisch wichtige Stellen und lass das Programm mit F9 rennen.

Also nach adoquerydruck.Open sollte keine Auswirkung haben.
Aber vor adoquerydruck.Open könnte ich mir einen Effekt vorstellen.
Arbeitest du mit vielleicht mit Access und befüllst die Tabelle "tempdruck" an anderer Stelle?

[Cosamia]

Ja, ich arbeite mit Access.

Die Tempdruck wird vorgelagert hier befüllt:

Delphi-Quellcode:

While Not ADOQuerydruck.Eof do
       begin

    {Linsentyp bestimmen}
    cltype := adoquerydruck.FieldByName('TYP').AsString;
    selectedid := adoquerydruck.FieldByName('Zahl').AsInteger;

    {Felder aus der INI lesen}
    IniFile := TIniFile.create(GetIniFilename);
        try
          clprintfields := IniFile.ReadString ('CLTYPES-PRINT',cltype,'');
        finally
          inifile.Free;
        end;
    {Printfields zusammensetzen / CL-Felder mit Stammdaten}
    Printfields := 'Name,Kundennummer,Strasse,Ort,PLZ,Fax,Telefon,EMail,Zahl,Kommission,'+clprintfields;

    {Felder aus der INI in ein SELECT bügeln / Stammdaten nicht vergessen}
    adoquerytemp.SQL.Clear;

    adoquerytemp.sql.text := 'insert into tempdruck ('+printfields+') SELECT '+printfields+' FROM qryDruck where zahl ='+inttostr(selectedid);
    adoquerytemp.ExecSQL;

    {nächsten Datensatz aus der Querydruck lutschen}
    adoquerydruck.Next;
        end; {For I}

[Cosamia]

unglaublich, aber leider wahr.

ein sleep (5000) funzt.
ein sleep (2000) scheint zu kurz, und ein sleep (3000) führt fast immer zum richtigen Ergebnis.

Ich habe es jetzt vor das Query.open gesetzt.

Kann mir jemand den Effekt erklären?

[Cosamia]

funktioniert aber auch nur, wenn ich weniger als 10 Datensätze habe.

Falls es mehr sind muss ich das sleep hochsetzen. :wall:

[Privateer3000]

Kann man nicht einfach mit
OnFetchComplete sicherstellen das
Open durchgeführt wurde.
Danach kann doch der Druck ausgeführt werden...

[shmia]

Zitat:

Zitat von Cosamia

Ja, ich arbeite mit Access.
Die Tempdruck wird vorgelagert hier befüllt:

Na dann hast du bestimmt verschiedene ADOConnections im Einsatz.
Du schreibst Daten über die eine Connection raus und liest sie über eine andere Connection wieder ein.
Da aber Access die Daten nicht sofort die die MDB-Datei schreibst, sondern erst nach ~ 2,5 Sekunden wegschreibt(Schreibcache), musst du eben warten.
Würdest du nur eine einzige ADOConnection verwenden, dann wäre alles in Butter.

Vielleicht hast du auch überhaupt kein einziges ADOConnection-Objekt im Einsatz und hast
überall nur den ConnectionString gesetzt.
Dann erzeugt die VCL pro Query eine eigene Connection - das ist natürlich ganz schlecht.

PS:
bei Access muss man überall die CursorLocation auf clUseServer setzen; das erhöht die Leistung.
Das gilt aber nur für Access; bei allen anderen DBs ist clUseClient in der Regel besser.

[Cosamia]

Ich handle das eigentlich alles über eine ADO.Connection.

[shmia]

Zitat:

Zitat von Cosamia

Ich handle das eigentlich alles über eine ADO.Connection.

Prüf' das nochmal, meine Nase sagt mir, dass du irgendwie zwei oder mehr Connections hast.

[Cosamia]

Mensch, deine Nase muss echt fein. Das war die Lösung.

Ich hatte ganz vergessen, dass ich der einen Query per Connectionstring die DB zugewiesen habe. :firejump: