Object wird manchmal nicht erzeugt

[Hobbycoder]

Danke für die Antwort.

Der Thread uSQLThread.SQLSaveCallActivity wird aus einem anderen WorkerThread heraus aufgerufen. Dieser hält die Klasse TDBSettings in dem Object FDBSettings, welches zu beginn des Threads erzeugt und erst am Ende wieder freigegeben wird. Der WorkerThread ist über die gesamte Programmlaufzeit aktiv und wird nicht unterbrochen oder neugestartet.
Weiterhin wird das Object FDBSettings noch an ganz viele andere Threads (ähnlich uSQLThread.SQLSaveCallActivity) übergeben, die andere Datenbank aufgaben erledigen.
Die laufen, auch an dem betroffenen PC, alle fehlerfrei. Von daher kann ich davon ausgehen, dass das Object auch noch existiert wenn es an die Create-Methode von uSQLThread.SQLSaveCallActivity übergeben wird.

Wie gesagt, ich habe das Problem nur an einem von 6 Clients, und kann mir das nicht erklären. Als Fehlermeldung bekomme ich eine EAccessViolation genau im Setter von TDBSettings.Hostname. Ich bekomme lediglich einen BugReport von MadExcept. Ich konnte auch bisher den Fehler bei mir nicht nachstellen oder nachvollziehen. Und, das kann ich den Datenbankeinträgen entnehmen, tritt er über die Programmlaufzeit nicht bei jedem Threadaufruf von uSQLThread.SQLSaveCallActivity auf. Und der ist auch über die gesamte Programmlaufzeit immer der gleiche, weil es dafür nur eine Procedure gibt.

Und doch bin ich mir ganz sicher, dass der Fehler irgendwo bei mir liegen muss. Normalerweise kann man, gerade bei EAccessViolation recht schnell den Punkt finde, wo ein Object fälschlicherweise nicht Erzeugt oder zu früh zerstört wurde. Aber der oben gezeigte Code läßt soch gar keinen Spielraum zu, in dem das passieren könnte. Oder übersehe ich was?

[hoika]

Hallo,

procedure TDBSettings.AssignTo(Dest: TObject);
var
sDestClassName: String;
begin
sDestClassName:= Dest.ClassName; // Test, ob hier MadExcept was anzeigt

if Dest is TDBSettings then

[Blup]

"Dest" ist mit sicherer Wahrscheinlichkeit vorhanden, sonst würde der vorherige Test mit "is" bereits fehlschlagen.
Ich vermute das an dieser Stelle "Self" = nil ist oder ungültig.

Auf EAccessViolation kann man sich nur verlassen, wenn auf nil-Pointer zugegriffen wird. Wenn der angesprochene Speicherbereich noch vom Speichermanager verwendet wird und somit das Programm noch das Recht hat auf disen Speicherbereich zuzugreifen, verhält sich das Programm eventuell nur merkwürdig.