Datenbanken und Statusmeldungen

[frankg]

Hallo Leute!

Ich habe heute mal eine Frage bzgl. Datenbanken und Statusmeldungen. Ich greife auf meine Datenbanken per ADO zu (direkt über die API, nicht über dbGo). Wie man Fehler, die von der Datenbank kommen behandelt weiss ich (Error-Objekt durchlaufen). Ich habe nun aber mal eine andere Frage: Wenn man sich über ein Kommandozeilen-Tool (z.B. SQL-Plus im Fall von Oracle) mit der Datenbank verbindet, dann kommen ja jede Menge Statusmeldungen, z.B. die Begrüssung durch die Datenbank. Wenn man dann mit der DB arbeitet (z.B. Delete * from Tab) dann gibt es ja auch Erfolgsmeldungen wie z.B. "10 records deleted". Wie kommt man denn an diese Meldungen (oder werden die vom Kommandozeilentool erzeugt)?

Viele Grüsse und vielen Dank

Frank

[Leuselator]

2. Teil der Frage: Nein - dei erzeugt die DB
1. Teil: muß gucken...

[Robert_G]

Diese Meldungen wie:
"Connected to Oracle8i Release 8.1.7.4.1
Connected as ...",
"5 records deleted",...
kommen von dem Tool, dass du nutzt.
Da du mit Oracle arbeitest hast du das große Los gezogen.
Nerve deinen Chef bis er die 229€ dafür ausgibt.
Diese Komponenten geben dir alle Infos, die du für Statusmeldungen à la SQL Plus brauchst.
p.s.: es gibt da auch eine Kompo names OracleScript, die sich genau wie SQl Plus verhält.

[Garby]

Zitat von GeorgeWNewbie:

Nerve deinen Chef bis er die 229€ dafür ausgibt.

...keine Investition, ein Muss für jeden der mit Oracle und Delphi arbeitet.

Zitat von GeorgeWNewbie:

Diese Komponenten geben dir alle Infos, die du für Statusmeldungen à la SQL Plus brauchst.

...und ausserdem läuft deine Anwendung schneller, stabiler und du hast Zugang zu so ziemlich allen Features von Oracle (auch 9i)

[frankg]

Hallo Garby, hallo GeorgeWNewbie, hallo Leuselator!

Erstmal vielen Dank für Eure Antworten. Ich werde mir das Tool auf jeden Fall mal ansehen. Insgesamt beantwortet dieser Tipp meine eigentliche Frage aber nicht, daher stelle ich sie hier noch einmal: "Gibt es eine Möglichkeit, wie man unter ADO an die Statusmeldungen der Datenbank nach dem Absetzen eines Befehls kommen kann?". Das mit Oracle war nur ein Beispiel um zu verdeutlichen, welche Meldungen ich meine. Der Weg muss über ADO gehen, damit man unabhängig von der jeweiligen Datenbank ist.

Viele Grüsse

Frank

[Garby]

Wie George schon schrieb, werden diese Meldungen meist vom Verwendeten Programm generiert.
Werden Datensätze mittels DELETE gelöscht wird manchmal die Anzahl der betroffenen Zeilen zurückgegeben.

Dies würde in Oracle dann ungefähr so aussehen:

SQL-Code:

Declare
  TYPE T_NumList is Table of Number;
  Enums T_NumList;';
begin
  Delete from EMP
   Where EMP_NO = :Nummer
  Returning 1 BULK COLLECT Into Enums;
  :Anzahl := Enums.Count;
end;

´
...und im Programm dann so:

Delphi-Quellcode:

with Query1 do begin
  Close;
  ParamByName('Nummer').asInteger := 1;
  Open;
  Panel1.Caption := ParamByName('Anzahl').AsString + ' Datensätze gelöscht.';
end;

Wie du siehst muss man sich i.d.r. um diese Statusmeldungen selber kümmern.
Von einer Automatisierung, wie z.B. ADOConnection1.GetLastMessage ist mir nichts bekannt.

[frankg]

Zitat von Garby:

Wie George schon schrieb, werden diese Meldungen meist vom Verwendeten Programm generiert.
Werden Datensätze mittels DELETE gelöscht wird manchmal die Anzahl der betroffenen Zeilen zurückgegeben.

...

Wie du siehst muss man sich i.d.r. um diese Statusmeldungen selber kümmern.
Von einer Automatisierung, wie z.B. ADOConnection1.GetLastMessage ist mir nichts bekannt.

Hallo Garby!

Vielen Dank für Dein Posting. Das mit der Anzahl der Datensätze ist aber recht kompliziert. Das kann man auch anders machen:

<Klugscheiss=ON >

Delphi-Quellcode:

uses
  AdoInt;

....

// Ich verwende hier eine TADOConnection, weil die einfacher in Delphi
// (besonders in der IDE) zu handhaben ist als ein _Connection-Objekt
procedure DoSomething (myConnection : TADOConnection);
var
  RowsAff : OleVariant;
  myADOCmd : ADOInt.Command;
begin
  if myConnection = nil then exit;
  try
    myADOCmd := CoCommand.Create;
    try
      if myConnection.Connected = FALSE then myConnection.Open;
      with myADOCmd do
        begin
          CommandType := adCmdStoredProc;
          CommandText := 'DELETE FROM BeispielTab WHERE Feld = 12';
          // Ich greife hier auf das unterliegende ADO-Objekt _Connection über
          // das TADOConnection Objekt zu.
          Set_ActiveConnection(myConnection.ConnectionObject);
          Execute (RowsAff, EmptyParam, adExecuteNoRecords);
          // In RowsAff steht ab hier dann die Anzahl der Zeilen, auf die sich der Befehl
          // ausgewirkt hat.
        end;
    except
      // Irgendwas hat da nicht geklappt!
    end;
  finally
     // Aufräumen
     myADOCmd := nil;
  end;
end;

<Klugscheiss=OFF >

Diese Weg hat mehrere Vorteile (siehe auch "ADO und Delphi" von Andreas Kosch). Da die dbGO-Implementation von Borland wohl nicht so doll ist, sind die wichtigsten Vorteile, dass diese Methode weniger Fehler verursacht und (wichtiger) das hier läuft viel schneller als über die dbGO-Komponenten. Da lohnt sich der zusätzliche Schreibaufwand dann wieder. Ausserdem muss man hier (im Gegensatz zu Deiner Lösung) nichts in der Datenbank selbst implementieren.

Aber nun zurück zur Ausgangsfrage:

Wenn ich also einen beliebigen SQL-String an eine Datenbank senden möchte und eine Ausgabe wie folgt erzielen möchte:

SQL-Code:

SQL> DELETE FROM Tabelle Where Feld = 1;

12 Datensätze gelöscht

SQL> ALTER TABLE Tabelle add NeuesFeld numeric;

Tabelle geändert

Muss ich also im Prinzip den SQL-Befehl vor-parsen (damit ich weiss, was gemacht werden soll) um dann die richtige Meldung ausgeben zu können? Sollte ein Fehler auftreten, ist es wieder einfacher, weil ich dann einfach das Errors-Objekt loopen kann und alles was da drin steht ausgeben kann. Ausserdem muss ich ja auch gucken, ob es sich um einen SELECT Befehl handelt, weil dieser dann ja eine Ergebnisdatenmenge zurückliefern kann.

Vielen Dank und viele Grüsse

Frank

[Garby]

Der obige Code von mir war nur als Beispiel gedacht.

Ansonsten triffts deine Beschreibung ziemlich genau.