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 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 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?