FireDac Debugen

[fisipjm]

Zitat von Edelfix:

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

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 von 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.

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.