FireDac Debugen

[Edelfix]

Warum lande ich in der CPU Ansicht wenn ich in der Delphi 12.3 IDE ein Fehler in der FireDac Komponente habe?

Ich meine nicht das die Komponente fehlerhaft ist, sondern ein Fehler beim verwenden der Komponente.

Der Fehler: "Erste Gelegenheit für Exception bei $00007FF8B7AEB699. Exception-Klasse EMySQLNativeException mit Meldung '[FireDAC][Phys][MySQL] You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near .."

Ich sehe das die SQL Syntax falsch ist aber in welcher Komponente oder Quelltext Zeile?

[QuickAndDirty]

Sind in den compileroptions debug-DCU angehakt? Wenn nicht, dann anhaken.

[fisipjm]

Zitat:

Zitat von Edelfix (Beitrag 1548434)

Warum lande ich in der CPU Ansicht wenn ich in der Delphi 12.3 IDE ein Fehler in der FireDac Komponente habe?

Welche Version von Delphi hast du im Einsatz? Der Quellcode zu Firedac ist erst ab Enterprise/Architect dabei. In der Pro version ist FireDac nur für Locale zugriffe und damit man das nicht umgeht, werden nur die DCUs mit ausgeliefert. Also hat deine IDE dann keine andere Chance.

[Edelfix]

Wenn ich es aktiviere lande ich in c:\program files (x86)\embarcadero\studio\23.0\SOURCE\RTL\SYS\Syste m.pas

In: procedure _InternalRaiseAtExcept(Obj: TObject; Address: Pointer; Reraise: Boolean);

und danach erst in der CPU Ansicht.

Ist eine Veränderung aber ich weiß leider immer noch nicht welche Komponente den Fehler verursacht.

Ich nutze die Pro Lizenz. Ich möchte die FireDac Quelltexte auch nicht sehen. Ich möchte nur wissen welche Komponente ich ändern muss.

[fisipjm]

Zitat:

Zitat von Edelfix (Beitrag 1548439)

Ich möchte nur wissen welche Komponente ich ändern muss.

Da deine Exception mit "Erste Gelegenheit für " anfängt würde ich einfach mal die Suche für diesen String über das ganze Projekt anwerfen.
Ansonsten CPU Ansicht schließen und "Ausführung bis Rückkehr" versuchen (Umschalt + F8, drittes debugger Symbol, ganz rechts).
Konnte mich bisher aber auch noch nicht erfolgreich der CPU Ansicht entledigen :oops:

Edit: Wenn deine Exceptio in einer Komponente erzeugt wird (z.B. Query auf einem Datamodule) dann wird's mit dem Debugger und ohne FireDac Quellcode so gut wie unmöglich die Stelle exakt zu bestimmen. Da hilft dann meist nur rantasten.

[DeddyH]

Wenn in der Meldung "to use near" steht, sollte danach ein Schnipsel des fehlerhaften SQL-Statements folgen. Danach kann man ja dann seine Komponenten durchsuchen.

[Edelfix]

Habe den fehlerhaften Quelltext gefunden. Es hat viel zu lange gedauert. Der Debuger war dabei aber leider überhaupt nicht hilfreich.

Es ist eine Stelle mit einer Query und dem Open Befehl der zur Exception führt. Die Stelle währe hilfreich.

Als ich versucht habe die Stelle mit try except ein zu klammern war die Klasse Exception aus der Unit Outlook2010.

Musste es erst etwas anpassen damit es funktioniert:

Delphi-Quellcode:

try
  Q1.Open;
except on E: System.SysUtils.Exception do
  s := E.Message;
end;

Könnte das der Grund sein ich in der CPU Ansicht gelandet bin?

Wichtiger währe zu wissen wie ich die CPU Ansicht komplett deaktivieren kann.

[Sinspin]

MadExcept oder ähnliche Tools können bei sowas wirklich sehr hilfreich sein.

Und wenn es sich rausstellt dass es bei dir doch aus Outlook2010 knallt bist Du damit leider aktuell nicht allein.
Ich hoffe Winzigweich macht das rückgänging was sie letztens am Patchday angerichtet haben.

[Uwe Raabe]

Zitat:

Zitat von Edelfix (Beitrag 1548447)

Habe den fehlerhaften Quelltext gefunden. Es hat viel zu lange gedauert. Der Debuger war dabei aber leider überhaupt nicht hilfreich.

Es ist eine Stelle mit einer Query und dem Open Befehl der zur Exception führt. Die Stelle währe hilfreich.

Ich hätte erwartet, dass die auslösende Zeile im Callstack zu sehen ist. In Lokale Variablen sollte man dann auch die SQL-Anweisung der betroffenen Query inspizieren können.

[Edelfix]

Habe ein Screenshot angehängt. Worauf soll ich achten? Was übersehe ich?

[Uwe Raabe]

Offenbar hast du bei der Query den ResourceOptions.CmdExecMode auf asynchron gestellt. Dann wird da in einem Thread ausgeführt und der Callstack zeigt die Quelle des Aufrufs nicht an.

Während des Debuggens empfehle ich daher, den CmdExecMode auf amBlocking zu stellen. Das kann ja z.B. in einem BeforeOpen-Event speziell für den Debug-Mode so eingestellt werden.

Eigentlich müsste man es auch mit dem Thread-Callstack sehen können, wenn man die lokalen Variablen in den aufrufenden Methoden des Stack untersucht. Das kann ich allerdings nicht verifizieren, da ich hier keine Pro-Version habe.

[Edelfix]

Uwe du hast mal wieder Recht. Habe nicht mehr daran gedacht.

Mit CmdExecMode auf amBlocking wird auch die Zeile im Quelltext innerhalb der CPU Ansicht angezeigt.

Danke.

[Sinspin]

Woran lag es dann jetzt? Aus dem Callstack hätte ich auf einen Fehler im SQL Script getippt.
Das ist so das übliche bei so einem Callstack, zigmal error handling, irgendwo etwas mit "Check*" und direkt davor wird es dann deutlich wärmer.
Aber wars das auch?

[Edelfix]

Der Fehler scheint doch noch nicht gelöst.

Es ist von Fall zu Fall unterschiedlich. Manchmal wird die Quelltext Zeile in der CPU Ansicht angezeigt und manchmal nicht.

Lässt sich die CPU Ansicht generell deaktivieren?

[Sinspin]

Du kannst verhindern dass die IDE anhält wenn es zu Fehlern kommt. Es gibt dann einfach nur die Meldung der Exception in einem hübschen Dialog.
Da es eh zu spät ist wenn es knallt, finde ich die CPU Ansicht zu diesem Zeitpunkt auch eher unpraktisch.
Wenn man selber durchsteppen will ist sie aber eine schöne Hilfe falls man irgendwo keine Quelltexte hat.
Ich würde es mit MadExcept oder einem anderen Tool zum Exception tracen probieren.
Der Fehler kann ganz woanders sein.