Arbeitsweise dbGo ADO Query Komponente

[Andidreas]

Hallo zusammen,

wir arbeiten bei uns unter anderem mit der DB2 Datenbank der IBM iSeries.
Seit dem letzten IBM Patches erhalten wir nachdem Ausführen von unseren SQL Statements z.T. sehr komische SQL Fehlermeldungen (z.B. SQL901 Systemfehler, usw.)...
Ein Ticket an die IBM haben wir bereits erstellt...

Nun habe ich zu meinem Verständnis eine Frage zur Arbeitsweise der ADO Query Komponente (befindet sich in meiner Delphi IDE auf dem Tabreiter dbGO in den Komponenten)...

Bei Programmstart stellen wir die Verbindung über eine TADOConnection.Open her.
Alle verwendeten Queries sind dann mit dieser TADOConnection verbunden.
Ein SQL Statement wird wie folgt zusammengesetzt:

Delphi-Quellcode:

  Try
    With (ADOQuery1) Do
    Begin
      Active := False;
      SQL.Clear;
      SQL.Add(' Select * From Table1 ');
      SQL.Add(' Where FLD01  <> ''1'' ');
      Active := True;
    End;
  Except
    ShowMessage('Fehler');
    Exit
  End;

Nun ist die Aussage der IBM u.a. das mit jedem SQL.Add der SQL Befehl an die DB abgesetzt wird, kann das sein?

[mkinzler]

Erst ein paar allgemeine Anmerkungen:
Warum with?
Warum Clear/Add statt Text?

Warum kein Open?

Delphi-Quellcode:

  Try
      //Active := False; überflüssig
      //SQL.Clear; überflüssig
      AdoQuery1.SQL.Text := ' Select * From Table1 ' +
                            ' Where FLD01 <> ''1'' ';
      AdoQuery1.Open; //Besser als Active
...

Zitat:

Nun ist die Aussage der IBM u.a. das mit jedem SQL.Add der SQL Befehl an die DB abgesetzt wird, kann das sein?

Kann ich mir nicht vorstellen, sonst wäre das ein großer Bug

[baumina]

Zitat von Andidreas:

Nun ist die Aussage der IBM u.a. das mit jedem SQL.Add der SQL Befehl an die DB abgesetzt wird, kann das sein?

Wie kommen die zu dieser Annahme? Erhalten die ständig unvollständige DB-Abfragen von deiner Software?

[Dejan Vu]

Mir ist zudem neu, das IBM etwas von Delphi versteht.

Ich würde im Except-Teil den genauen Fehler mit ausgeben.

[DeddyH]

Ich würde das zusätzlich noch das with eliminieren und die Abfrage parametrisieren.

Delphi-Quellcode:

Try
  ADOQuery1.Close;
  ADOQuery1.SQL.Text := ' Select * From Table1 Where FLD01 <> :SomeValue';
  ADOQuery1.Parameters.ParamByName('SomeValue').Value := '1';
  ADOQuery1.Open;
Except
  on E: Exception do
    ShowMessage('Es ist ein Fehler aufgetreten: ' + E.Message);
  Exit
End;

[Sir Rufo]

Ich würde das try except ganz weglassen, denn behandelt werden soll da nichts. Die Anzeige der Ausnahme erfolgt automatisch, unverfälscht und pur.

Man sieht direkt was für eine Fehlerklasse und den Text.

Aber warum einfach, wenn kompliziert ...

[Bernhard Geyer]

Was passiert wenn du die entsprechenden SQL-Statements direkt auf der DB (mit IBM-Querytool) ausführst.
Manchmal machen solche Patches mehr kaputt als sie reparieren.

Alternativ ist natürlich immer die ADO/OLE DB-Schnittstelle gut für Probleme. M.E. kann man sie nur für MS-Datenquellen einsetzen.
Also wenn die Queries direkt funktionieren wäre Schnittstelle u.U. ein Problem wenn z.B. der Provider einfach nicht mehr mit diesem patch-Level zusammenspielt. Was wird den für ein Provider genommen?

[p80286]

Zitat von Andidreas:

Bei Programmstart stellen wir die Verbindung über eine TADOConnection.Open her.

Warum?

Delphi-Quellcode:

aq.close;
aq.sql.text:='select irgendwas from irgendwo where wert=1';
aq.open;
while not aq.eof do begin
 ...
  aq.next;
end;
aq.close;

mehr braucht man nicht um funktionierende Abfragen zu haben.
Parameter und ggf. der Zugriff auf das recordset sind für Tests erst einmal unnötig, für den laufenden Betrieb aber nicht zu verachten.

Gruß
K-H