Hallo zusammen,

bei einem größeren Datenbankimport-Programm (aus XML-Files) muss ich bei auftretenden Fehlern sehen können, welches SQL-Insert mit welchen Werten(!) evtl.. einen Fehler verursacht hat. Ich wende bei der Query SQL-Parameter an (ziemlich viele). Somit kann ich ja nicht
FDQry.SQL.Text ausgeben, dann sehe ich ja nur die Parameter.

Vermutlich muss ich mir tatsächlich dann für die Protokollierung das SQL-Statement alles mit Hand zusammenbasteln um die Werte zu sehen.

Oder gibt es da eine einfachere Möglichkeit?

Ich hoffe ich konnte mein Anliegen verständlich rüberbringen.

Vielen Dank schon mal vorab!

Du brauchst ein Logging/Tracing Tool für die Datenbank. Der "SQL Server Profiler" sollte das können.

Oder den FireDAC FDMonitor verwenden: Ablaufverfolgung und Überwachung (FireDAC)

Vielen Dank für eure Antworten!

Der Ansatz mit FDMonitor scheint für meinen Fall sehr interessant.
Ich würde dem User dann eine Option bereitstellen, womit er das Tracing im Fehlerfall aktivieren kann.


Einen schönen Sonntag noch!

Du kannst Dir auch eine abgeleitete Komponente eines Queries deiner Wahl bauen und die Open und Execute Methoiden überschrieben, in welchen Du im Fehlerfall das SQL und Dir parameter Dir per Mail schickst oder an CodeSite sendest (je nachdem ob du es in Produktion oder Entwicklung brauchst)

Ist das hier beschriebene nicht einfacher?

http://docwiki.embarcadero.com/Libra...stomQuery.Text

Zitat von FireDAC.Comp.Client.TFDCustomQuery.Text:

Up to Parent: TFDCustomQuery

Delphi

property Text: String read GetText;

C++

__property System::UnicodeString Text = {read=GetText};

Properties
Type Visibility Source Unit Parent
property public
FireDAC.Comp.Client.pas
FireDAC.Comp.Client.hpp
FireDAC.Comp.Client TFDCustomQuery
Description

Points to the actual text of the SQL query passed to the DBMS CLI.

Text is a read-only property that can be examined to determine the actual contents of the SQL statement passed to the DBMS. For parameterized queries, Text contains the SQL statement with parameters replaced by the parameter substitution symbol (? or another symbol) instead of actual parameter values, substituted macro values, and processed escape sequences.

In general, there should be no need to examine the Text property. To access or change the SQL statement for the query, use the SQL property. To examine or modify parameters, use the Params property.

To check what FireDAC sends to the DBMS, consider to use FireDAC monitoring.

Wenn ich das recht verstehe, enthält das Attribut Text von FDQry, also hier konkret FDQry.Text (und nicht FDQry.SQL.Text) den Inhalt der Abfrage, nach dem Auflösen der Parameter im SQL durch die entsprechenden Parameterwerte. Sprich das, was konkret an die Datenbank geschickt wird.

Es dürfte demnach das Gewünschte "von Haus aus" bereits zur Laufzeit im Programm zur Verfügung stehen, ohne irgendwelche weiteren Hilfsmittel.

Quasi sowas:

markieren

Delphi-Quellcode:

FDQry.SQL.Text := 'insert into tabelle (id, wert) values (:id, :wert);
FDQry.ParamByName('ID').AsInteger := 1;
FDQry.ParamByName('Wert').AsString := 'irgend eine Zeichenfolge';
FDQry.Prepare;
if MessageDLG('Ist das Statement ' +#13#13 + FDQry.Text + #13 'so korrekt?',mtConfirmation,[mbYes,mbNo],0) = mrYes then FDQry.ExecSQL;

Nur hingedaddelt ohne jegliche Testmöglichkeit
Zumindest suggeriert die Hilfe, dass das in etwa so funktionieren könnte.

Zitat von Delphi.Narium:

Ist das hier beschriebene nicht einfacher?

Interessant!
Das ist einfach zu einfach!

Im Ernst:
Ich hab das grad getestet. Zu ca. 70% scheint das zu funktionieren!
Es gibt aber auch viele Werte wo dann nur ein "?" drin steht. U.a. auch dann wenn es kein Parameter ist sondern ein direkt zugewiesener Wert.
Warum das so ist hat sich mir noch nicht erschlossen.

Zitat von juergen:

Es gibt aber auch viele Werte wo dann nur ein "?" drin steht. U.a. auch dann wenn es kein Parameter ist sondern ein direkt zugewiesener Wert.

Da steht ja auch

Zitat:

For parameterized queries, Text contains the SQL statement with parameters replaced by the parameter substitution symbol (? or another symbol) instead of actual parameter values, substituted macro values, and processed escape sequences.

Es ist ja wirklich so, daß der parametrisierte SQL-Text an den Server geschickt wird und die aktuellen Parameter davon getrennt übertragen werden. Nur so kann man ja für verschiedene Parametersätze die bereits vorbereitete Query verwenden, in dem man dem Server nur noch die neue Parameter übergibt. Nirgendwo auf diesem Weg wird ein String erzeugt, der das SQL mit den aktuellen Parameterwerten enthält. Das wirst du auch nicht im FDMonitor sehen. Dort kommen die Parameter auch in einem separaten Aufruf.

Habe mir das nun am PC angeschaut.
Mein Post #7 war voreilig entstanden, da hatte ich mich nur mit meinem Tablet auf meinen PC verbunden und einen oberflächlichen Test gemacht. Der Vorschlag von Delphi.Narium mit Verwendung von FDQry.Text hilft leider nicht (auch wenn sich die Hilfe da so deuten lässt).

Fazit:
1. Ich hab es nun so verstanden, dass bei Verwendung von Query-Params die den Params zugewiesenen Werte *nicht* in *einem* SQL-Statement direkt darstellen lassen
2. Durch Nutzung von FDMonitor (siehe Post #3 von Uwe) ist es möglich an die Werte ran zukommen. Aber auch hier nicht direkt im dargestellten SQL-Statement sondern in einer späterer Auflistung der Parameter-Werte. Die sehen dann z.B. so aus:

markieren

Code:

Param [N=1, Name="RecID_A4", Mode=INPUT, Type=SLONG, Size=0, Len=4, Data(0)=36]

Das Tracing ist einfach zu handhaben und hilft mir auch noch anderen Stellen weiter!

Zitat:

Ich hab es nun so verstanden, dass bei Verwendung von Query-Params die den Params zugewiesenen Werte *nicht* in *einem* SQL-Statement direkt darstellen lassen

Das ist ja der Vorteil von parametrisierten Abfragen. Es sind halt mehr als Makros. Die Abfrage kann vorab vom Server unabhängig von den Werten "kompiliert" werden (PLAN usw.)
Beim Ausführen werden nur noch die Parameter an den Server gesendet und können sofort für die vorbereitete Abfrage verwendet werden.