SQL mitloggen

[Captnemo]

Hi,

unter Zeos gab es eine Komponente (ich glaube ZSQLMonitor, oder so), mit der konnte man bequem die SQL-Statements mitloggen zur Fehleranalyse.
Und zwar die SQL-Statement nach dem prepare.

Gibt es so ähnliches auch für die ADOConnection der dbGo-Komponenten?

[Bernhard Geyer]

Nimm doch den Tracer vom MS SQL Management Studio

[Captnemo]

Ui...wo finde ich den?
Gibt's den auch bei 2005 Express mit 2008 Management Console?

Weiß jemand eine Möglichkeit, die ich im Programm einbauen kann?

[p80286]

http://www.aboves.com/?ado

Gruß
K-H

[EgonHugeist]

Den TZSQLMonitor giebt es bei Zeos übrigens immernoch!

Für Zeos + MsSQL/Sybase habe ich FreeTDS Lib implementiert, welches im Gegensatz zu ADO Blitz schnell ist. ADO ist ne tolle "genormte" Sache, wenn man den Server dahinter nicht kennt. Dennoch ist es im Gegensatz zum native TabularDataStream (TDS) schnarch langsam.

schau mal hier rein http://sourceforge.net/projects/zeos...bo-7.0.1-beta/

Gruß Michael

[Stevie]

Eventuell hilft dir dieser Artikel

[p80286]

[OT]
Mir geht das Herumgehacke auf ADO langsam gewaltig auf den Geist. Abgesehen von der Abkündigung des Oracle-Treibers von MS, und einigen Macken der Treiber, hat ADO einen riesen Vorteil, das ist out of the Box verfügbar, und man muß nicht stundenlange Surf- und Konfigurationsorgien auf sich nehmen. Bis das diese blitzschnellen SuperDBanbindungen laufen, hat das schnarchlangsame ADO schon so viel Vorsprung, daß er gar nicht mehr eingeholt werden kann.
[/OT]

Gruß
K-H

[Bummi]

Ich hatte den von Stevie angegebene Link mal weggekapselt, geloggt wird in einem Clientdataset

Die Aufrufe beschränken sich auf:

Delphi-Quellcode:

TDisplayLog.Execute(Self,AC,panel1).Show;
//oder
var
 r:Trect;
begin
  r := BoundsRect;
  OffsetRect(r,20,20);
  With TDisplayLog.Execute(Self,AC) do
    begin
      BoundsRect := r;
      Show;
    end;
end;
// und
 TDisplayLog.Execute(Self,AC).Free;

Wer kein cxGrid einsetzt müsste hier ein anderes DBGrid einbauen...

[Captnemo]

Ich hab das auch mal so wie im Link von Steve angegeben umgesetzt.

Ist schon mal eine ganz schöne Sache. Aber mir fehlen noch die Paramter, um die es mir an dieser Stelle ja eigentlich geht. Ich hätte gerne das komplette SQL-Statement nach dem Prepare.

Mit einem

Code:

Insert into blabla (feld1, feld2, feld2) VALUES (?,?,?)

kann ich für meine Zwecke jetzt nicht so viel anfangen.
Aber der Ansatz ist natürlich schon mal super.

@Bummi: Hm.....versteh grad den Sinn deines Codes nicht.....hilf mir mal auf die Spünge.

@p80286: Hier geht es ja nicht um Herumhacken auf ADO. Ich nutze es ja, weil mir das ganze Komponenteninstallieren von Zeos auf den Keks ging. Ich such halt nur ne Möglichkeit um die SQL-Statements vernüftig mitzuloggen.

Ich hab nämlich grad den Fall, dass ich ein Datumswert in die MS-DB schreibe, und hinterher festgestellt habe, dass in der DB das Datum + 2Tage drin ist. Jetzt würde mich natürlich das SQL-Statement brennend interessieren.

[mkinzler]

Zitat:

Ist schon mal eine ganz schöne Sache. Aber mir fehlen noch die Paramter, um die es mir an dieser Stelle ja eigentlich geht. Ich hätte gerne das komplette SQL-Statement nach dem Prepare.

Das wirst du clientseitig nicht hinbekommen. Die Parameter werden ja direkt vom Server angewendet.

[jobo]

hier gibts in den Kommentaren noch einen Hinweis von Rodrigo
http://theroadtodelphi.wordpress.com...do/#comment-52

[Captnemo]

Zitat:

Zitat von mkinzler (Beitrag 1188138)

Zitat:

Ist schon mal eine ganz schöne Sache. Aber mir fehlen noch die Paramter, um die es mir an dieser Stelle ja eigentlich geht. Ich hätte gerne das komplette SQL-Statement nach dem Prepare.

Das wirst du clientseitig nicht hinbekommen. Die Parameter werden ja direkt vom Server angewendet.

Aber der SQL-String muß ja erst einmal aufbereitet werden, bevor er zum Server gesendet wird. Der server kann ja mit

Code:

insert into kunden (name1, name2, strasse, plz, ort) VALUES (:name1, :name2, :strasse, :plz, :ort)

nicht soviel anfangen.
Und diese Aufbereitung muß ja innerhalb der ExecSQL-Procedure stattfinden. Und genau des aufbereiteten SQL-String möchte ich gerne haben.

[mkinzler]

Doch kann er, das ist ja gerade der Vorteil von Parametern. Beim ExecSQL werden nur die Werte der Parameter an den Server gesendet, welche er dann auf den vorbereitete Abfrage anwendet.

[p80286]

Zitat:

Zitat von Captnemo (Beitrag 1188136)

@p80286: Hier geht es ja nicht um Herumhacken auf ADO. Ich nutze es ja, weil mir das ganze Komponenteninstallieren von Zeos auf den Keks ging. Ich such halt nur ne Möglichkeit um die SQL-Statements vernüftig mitzuloggen.

Du warst auch nicht gemeint, Nichts für ungut.

Gruß
K-H

P.S.
was die Parameter angeht, schau mal in die Kommentare zu Stevies Link.
Ich bin mir nicht sicher, aber der Tracer den ich verlinkt habe liefert das, soweit ich mich erinnern kann.

[Captnemo]

Zitat:

Zitat von mkinzler (Beitrag 1188146)

Doch kann er, das ist ja gerade der Vorteil von Parametern. Beim ExecSQL werden nur die Werte der Parameter an den Server gesendet, welche er dann auf den vorbereitete Abfrage anwendet.

Gut, dann bleibt für mich die Frage: Machen die ADO-Komponenten es genau so? Kannst du mir das auch beantworten?
(MSSQL2005Express, XE2, dbGo ADOConnection)

Denn wenn ja, kann ich mir das ganze schenken. Denn ich kann das Logging nur gebrauchen, wenn ich auch sehen kann, welche Werte an den Parametern eingesetzt werden.
Leider habe ich noch kein Programm gefunden, womit ich mir das ganze am SQL 2005 Express mitloggen kann (zumindest keine kostenlose).

[Bummi]

Hier noch 2 Ansätze:

http://www.codeproject.com/Tips/3322...hout-using-SQL

http://www.techrepublic.com/blog/dat...es-in-tsql/159
http://blogs.msdn.com/b/sqlsecurity/...-profiler.aspx

[shmia]

Also man kann sich auch in die Events der ADOConnection einklinken und so Queries mitprotokollieren.
Bei folgendem Code-Schnipsel habe ich einige Dinge ausgeschnitten (betreffend Zeitmessung),
aber das Prinzip müsste klar sein.

Delphi-Quellcode:

procedure TMainDataModule.ConnectionExecuteComplete(Connection: TADOConnection;
  RecordsAffected: Integer; const Error: ADODB.Error;
  var EventStatus: TEventStatus; const Command: _Command;
  const Recordset: _Recordset);

{  Komplett auskommentiert, da ab und an Fehler auftreten (Command.Parameters.Item[i] ist nil, wiesoauchimmer).
   Ist eh nur für Zeitmessungen interessant, wenn man die Parameter der Query wissen will.
    
   function GetMoreInfo: string;
   var
      i: Integer;
   begin
      Result := 'RecordsAffected: ' + IntToStr(RecordsAffected);
      try
         if Command.Parameters.Count > 0 then
         begin
            Result := Result + ', ' + IntToStr(Command.Parameters.Count) + ' Parameter: ';

            for i := 0 to Command.Parameters.Count-1 do
            begin
               if i > 0 then
                  Result := Result + ', ';
               Result := Result + '"' + Command.Parameters.Item[i].Name + '" = "' + VarToStr(Command.Parameters.Item[i].Value) + '"';
            end;
         end;
      except
      end;
   end;
}   
var
   sql: string;
   //time: Integer;
   ms: Double;
begin
  // time := GetTickcount-FSQLExecTime;

  sql := CleanupSQL(Command.CommandText);

  // Alle Whitespaces durch ein einzelnes Leerzeichen ersetzen.
  // und mehrfache Leerzeichen auf eines reduzieren
  sql := StrRemoveSequentialChars(StrReplaceChars(sql,[#13,#10,#9],' '),[' ']);
  FTimeLogger.WriteLogFileFmt('SQL %7.1f ms: %s', [ms,sql]);
  //FTimeLogger.WriteLogFile('                ' + GetMoreInfo);
end;

function CleanupSQL(const sql: string): string;
var
   i: Integer;
begin
   // Teilweise werden von den Command-Objekten SQL-Strings zurückgegeben, die
   // mittendrin ein #0 Zeichen haben => Dort abschneiden.
   i := CharPos(sql,#0,1);
   if i > 1 then
      Result := Copy(sql,1,i-1)
   else
      Result := sql;
end;

[Bummi]

@shmia

#6,#8,#9