Mysteröse Zugriffsverletzung

[Getox]

Hallo,

ich habe einen ganz komischen Fehler. Da ich Aiman Abdallah nicht erreichen konnte, wollte ich fragen ob hier jemand eine Idee hat

Ich habe hier eine Datenbankverbindung und habe eine SQL-Abfrage mit einem tDataSet geöffnet. Das klappt eigentlich immer reibungslos. Nun habe ich aber an einer Stelle eine Fehlermeldung bekommen. Eine Zugriffsverletzung bei Adresse Bla... wie immer nicht aussagekräftig.

Ich bin dann beim debuggen auf die Stelle gestoßen, wo der Fehler passiert:

Code:

Result := DSet.FieldByName(Field).Value;

Das verrückte ist nun, wenn ich dort einen Haltepunkt setze und die Maus auf "Value" halte, steht im Tooltip der Text mit der Zugriffsverletzung. Wenn ich jetzt die Maus woanders hin bewege und anschließend ein zweites Mal auf "Value" halte, steht im Tooltip plötzlich NULL. Wenn ich dann das Programm weiterlaufen lasse, läuft alles fehlerfrei. Aber ich kann mich ja nicht debuggend zu den Kunden setzen und immer wenn sie diese Stelle öffnen die Variable 2 Mal anschauen...

Ich hab schon bereinigt und neu erzeugt. Ich habe das Projekt schon an einem anderen Rechner erzeugt (Meiner hat XE3 und der andere XE4) und der Fehler taucht immer noch auf. Ich bin echt langsam ratlos.

[ConnorMcLeod]

DSet beinhaltet ein gültiges Objekt?
FieldBaName(Field) liefert ein TField und nicht nil?
Result und .Value sind kompatibel?

[Getox]

Zitat von ConnorMcLeod:

DSet beinhaltet ein gültiges Objekt?
FieldBaName(Field) liefert ein TField und nicht nil?
Result und .Value sind kompatibel?

Ja. Habe ich alles überprüft und läuft auch im Normalfall. Daher bin ich ja so ratlos. Vor allem: Das Programm steht ja an einer Stelle. Ich debugge ja nicht weiter... es steht am Haltepunkt und wenn ich einmal die Maus auf Value halte, stehtz dort die Zugriffsverletzung und beim Zweiten mal (wie es korrekt ist) NULL. Ich habe aber nicht weiter gesteppt oder so.

[hoika]

Hallo,
du gehst also 2mal mit der Maus drüber, während das Programm angehalten ist?

DSet ist eine normale Variable oder ein Property.
Arbeitest Du mit Threads?

Beachte:
Das Anzeigen eines Watch-Point kann auch Code ausführen.

[Uwe Raabe]

Zitat von ConnorMcLeod:

FieldBaName(Field) liefert ein TField und nicht nil?

FieldByName liefert niemals nil! Allenfalls wirft es eine Exception.

Delphi-Quellcode:

function TDataSet.FieldByName(const FieldName: string): TField;

  procedure Error;
  begin
    DatabaseErrorFmt(SFieldNotFound, [FieldName], Self);
  end;

begin
  Result := FindField(FieldName);
  if Result = nil then Error;
end;

[ConnorMcLeod]

Das kommt davon, daß ich immer FindField verwende ...

[Getox]

Zitat von hoika:

Hallo,
du gehst also 2mal mit der Maus drüber, während das Programm angehalten ist?

DSet ist eine normale Variable oder ein Property.
Arbeitest Du mit Threads?

Beachte:
Das Anzeigen eines Watch-Point kann auch Code ausführen.

ja, ich bin 2 Mal mit der Maus über die Variable gefahren, während das Programm am Breakpoint stand.

Value ist tatsächlich eine Property, die das selbe macht wie asVariant:

Code:

property Value: Variant read GetAsVariant write SetAsVariant;
property AsVariant: Variant read GetAsVariant write SetAsVariant;

Und nein, es werden keine Threads verwendet (es sei denn diese werden im Hintergrund von Delphi oder irgendwelchen Komponenten erzeugt).

Ich habe nun an der Stelle nicht mehr den variantValue abgefragt und auf Null geprüft, sondern ich frage das Feld asInteger ab und schaue ob das Ergebnis 0 ist. Das klappt reibungslos. Seltsam ist es dennoch.

Zitat von Uwe Raabe:

Zitat von ConnorMcLeod:

FieldBaName(Field) liefert ein TField und nicht nil?

FieldByName liefert niemals nil! Allenfalls wirft es eine Exception.

Das Feld selbst kann ich ja auch problemlos abfragen und in eine Variable legen. Erst wenn ich mit einer der beiden oben genannten Properties auf den variantValue zugreifen will passiert das. Und auch nur an dieser einen Stelle im Code. Das ist ja eine Funktion die schon seit Ewigkeiten an sehr vielen Stellen verwendet wird - immer wenn man wissen will ob ein Feld NULL ist. Und es gab nie Probleme, bis auf jetzt.

Code:

function TKlassenname.IsNull(Field: String): Boolean;
begin
  Result := (getVariantValue(Field) = NULL);
end;

function TKlassenname.getVariantValue(Field: string): Variant;
begin
  Result := DSet.FieldByName(Field).Value;
end;

[bcvs]

Warum fragst eigentlich nicht gleich IsNull ab?

Delphi-Quellcode:

function TKlassenname.IsNull(Field: String): Boolean;
begin
  Result := DSet.FieldByName(Field).IsNull;
end;

Das Variant ist mir immer etwas suspect. Nicht umsonst ist Delphi so schön typsicher.

[Getox]

Zitat von bcvs:

Warum fragst eigentlich nicht gleich IsNull ab?

Delphi-Quellcode:

function TKlassenname.IsNull(Field: String): Boolean;
begin
  Result := DSet.FieldByName(Field).IsNull;
end;

Das Variant ist mir immer etwas suspect. Nicht umsonst ist Delphi so schön typsicher.

Das ist historischer Code an zentraler Stelle. Da darf ich wenn es sich vermeiden lässt nichts dran ändern. Aber wenn ich testweise beim Feld isNull abfrage kommt der Fehler auch. Wie gesagt... an der einen besagten Stelle frage ich nun einen Int ab und teste diesen auf 0. Das klappt.

[hoika]

Hallo,
wenn das nicht beim gesetzten Breakpoint wäre,
würde ich darauf tippen, dass die Speicher überschreibst.
FastMM4 wäre dann ein Mittel zum Zweck.