Variablen werden überschrieben!?

[-187-]

Hallo,

ich steh vor einem komischen Problem. Und zwar scheint es als würden die Werte meiner Variablen auf Grund eines Methodenaufruf's überschrieben werden.
Jedenfalls konnte ich das im Debugger beobachten. Hat jemand eine Idee?

Delphi-Quellcode:

procedure TDemoForm.Button1Click(Sender: TObject);
var
  CurrentRow: Integer;
  maxExport : Integer;
  Next : Boolean;

  A: PersonDef;
  Current: PersonDef;
  RefNr: LongInt;
  Key: IsamKeyStr;
begin
  CurrentRow := 0;
  maxExport := 0;
  Next := true;
  while ((Next = true) and (maxExport < 100)) do
  begin
    Next := NextRecord(A, RefNr, 1, Key, true);
    if (Next = true) then
      BTGetRec(PersFB, RefNr, Current, False); //nach dem Aufruf dieser Methode ist "Next" z.B "false", warum?
    Inc(CurrentRow);
    Inc(maxExport);
  end;
end;

PS: Dazu ist noch zu sagen das "BTGetRec" eine Methode von BTreeFiler ist.

[Sir Rufo]

Entferne dringend mal das

Delphi-Quellcode:

= true

und probiere es nochmal

BTW Ist

Delphi-Quellcode:

BtGetRec

eine Funktion oder Procedure?

[-187-]

Zitat:

Zitat von Sir Rufo (Beitrag 1194346)

Entferne dringend mal das

Delphi-Quellcode:

= true

und probiere es nochmal

BTW Ist

Delphi-Quellcode:

BtGetRec

eine Funktion oder Procedure?

Danke für deine Antwort. Das entfernen von = true ändert nichts. Es handelt sich um eine Procedure:

Delphi-Quellcode:

procedure BTGetRec;(IFBPtr : IsamFileBlockPtr; RefNr : LongInt; var Dest; ISOLock : Boolean);

(Aus der Doku)

[Popov]

Ob du

Delphi-Quellcode:

Next = true

vergleichst oder einfach nur

Delphi-Quellcode:

Next

ist gehopst wie gesprungen.

Next ist True

Next = true ergibt True
Next ergibt True

Next ist False

Next = true ergibt False
Next ergibt False

Vergleiche mit True oder False kannst du dir also sparen. Die Boolean-Variable reicht für sich allein.

[-187-]

Zitat:

Zitat von Popov (Beitrag 1194349)

Ob du

Delphi-Quellcode:

Next = true

vergleichst oder einfach nur

Delphi-Quellcode:

Next

ist gehopst wie gesprungen.

Ja der Meinung war ich auch. Jedoch schreibe ich es weil ich's lesbarer finde. Gewohnheit..

[Sir Rufo]

Zitat:

Zitat von Popov (Beitrag 1194349)

Ob du

Delphi-Quellcode:

Next = true

vergleichst oder einfach nur

Delphi-Quellcode:

Next

ist gehopst wie gesprungen..

Das stimmt leider nicht, denn

Delphi-Quellcode:

Next = true

und

Delphi-Quellcode:

Next

können unterschiedliche Ergebnisse liefern.

Delphi-Quellcode:

if Next

ist wie

Delphi-Quellcode:

if Next <> False

und

Delphi-Quellcode:

if Next = true

stimmt nur dann, wenn in

Delphi-Quellcode:

Next

eine 1 enthalten ist.

Das ist auch der Grund, warum man nie auf true prüfen soll

Zitat:

Zitat von -187- (Beitrag 1194350)

Zitat:

Zitat von Popov (Beitrag 1194349)

Ob du

Delphi-Quellcode:

Next = true

vergleichst oder einfach nur

Delphi-Quellcode:

Next

ist gehopst wie gesprungen.

Ja der Meinung war ich auch. Jedoch schreibe ich es weil ich's lesbarer finde. Gewohnheit..

Versuch doch mal die Variable umzubenennen in

Delphi-Quellcode:

HasNext

dann liest sich das viel besser und das (fehlerträchtige)

Delphi-Quellcode:

= true

sieht irgendwie komisch aus, was es halt auch ist. ;)

[-187-]

Zitat:

Zitat von Sir Rufo (Beitrag 1194351)

Delphi-Quellcode:

if Next

ist wie

Delphi-Quellcode:

if Next <> False

und

Delphi-Quellcode:

if Next = true

stimmt nur dann, wenn in

Delphi-Quellcode:

Next

eine 1 enthalten ist.

Das ist ja mal gut zu wissen! :thumb:

Aber jetzt doch bitte back2topic :)

[Sir Rufo]

Bist du mit dem Debugger denn schon mal durch diese Routine BTGetRect gelaufen und hast geschaut, ab wann in Next auf einmal False steht?

Irgendwann muss das dort ja passieren

[Popov]

So wie ich das gemeint habe stimmt es schon. Ich hab es später konkretisiert. In dem ersten Fall habe ich gemeint, dass wenn Next True ist, es gehopst wie gesprungen ist ob man mit

Delphi-Quellcode:

Next = true

vergleicht oder einfach nur mit

Delphi-Quellcode:

Next

. Ich dachte es wird so verstanden.

Ob man es prüft oder nicht ist so eine Sache. In Visual Basic hat man es geprüft. Ich bin von VB Programmieren ständig drauf hinweisen, dass ich da was vergessen habe. Wenn es in einer Sprache üblich ist, kann es in einer anderen nicht falsch sein, höchstens unnötig.

[-187-]

Zitat:

Zitat von Sir Rufo (Beitrag 1194353)

Bist du mit dem Debugger denn schon mal durch diese Routine BTGetRect gelaufen und hast geschaut, ab wann in Next auf einmal False steht?

Irgendwann muss das dort ja passieren

Nein, ich weiss auch nicht wie ich da ran komme. Alles was ich gefunden habe ist: (FILER.PAS)

Delphi-Quellcode:

Procedure BTGetRec (     IFBPtr  : IsamFileBlockPtr;
                           RefNr   : LongInt;
                       Var Dest;
                           ISOLock : Boolean );
    {-Gets the specified record from the given reference}

Edit: Moment, habe noch eine Filer.inc gefunden. Muss mal schauen wie ich die einbinden, sodass ich über den Debugger drauf zugreifen kann.

[Sir Rufo]

Zitat:

Zitat von -187- (Beitrag 1194356)

Zitat:

Zitat von Sir Rufo (Beitrag 1194353)

Bist du mit dem Debugger denn schon mal durch diese Routine BTGetRect gelaufen und hast geschaut, ab wann in Next auf einmal False steht?

Irgendwann muss das dort ja passieren

Nein, ich weiss auch nicht wie ich da ran komme. Alles was ich gefunden habe ist: (FILER.PAS)

Hmmm, Haltepunkt auf die Zeile mit dem Aufruf von BTGetRect, mit F9 das Programm im Debugger starten und sobald das Programm dort anhält mit F7 weitergehen, bei jedem weiteren Schritt (F7 oder F8) immer wieder den Wert von Next in deiner Methode überprüfen.

[Bummi]

:gruebel: klingt ein bisschen wie ein Stackfehler in/um die Prozedur ....

[Popov]

Zitat:

Zitat von -187-

...

Ich will dem Debuger nicht widersprechen, aber kannst du einen simplen Test machen? Bist du sicher, dass Next True ist?

Delphi-Quellcode:

var
  TmpNext: Boolean; //<<<
  ...
begin
  ...
    Next := NextRecord(A, RefNr, 1, Key, true);
    TmpNext := Next; //<<<
    if (Next = true) then
      BTGetRec(PersFB, RefNr, Current, False);
    if Next = TmpNext then ShowMessage('Gleich: ' + BoolToStr(Next)) else ShowMessage('Ungleich'); //<<<
  ...
end;

[Sir Rufo]

Zitat:

Zitat von Bummi (Beitrag 1194358)

:gruebel: klingt ein bisschen wie ein Stackfehler in/um die Prozedur ....

Sowas habe ich da auch im Kopf, evtl. noch ein Seiteneffekt von

Delphi-Quellcode:

Next := NextRecord(A, RefNr, 1, Key, true);

[Sir Rufo]

Ich habe mal alles überflüssige und evtl. Seiteneffekte erzeugende entfernt.
Schau mal, ob das funktioniert, wie gewünscht:

Delphi-Quellcode:

procedure TDemoForm.Button1Click( Sender : TObject );
var
  CurrentRow : Integer;
  A :       PersonDef;
  Current : PersonDef;
  RefNr :   LongInt;
  Key :     IsamKeyStr;
begin
  CurrentRow := 0;
  while ( CurrentRow < 100 ) and NextRecord( A, RefNr, 1, Key, true ) do
    begin
      BTGetRec( PersFB, RefNr, Current, False );
      Inc( CurrentRow );
    end;
end;

[-187-]

Delphi-Quellcode:

procedure BTGetRec(IFBPtr  : IsamFileBlockPtr;
                   RefNr   : LongInt;
               var Dest;
                   ISOLock : Boolean);
  {-Gets the specified record from the given reference}
var
  Options : Word;
begin
  if ISOLock then begin
    Options := NoOptions;
  end
  else begin
    Options := OptReadPrefix;
  end;
  IsamEntryCode(IFBPtr, Options);
  if IsamOK then
    IsamGetRec(IFBPtr, RefNr, Dest);
  if IsamOK then begin                                         {!!.50}
    IFBPtr^.CharConvProc(@Dest, IFBPtr^.DIDPtr^[0]^.LenRec,    {!!.50}
        True, IFBPtr^.CCHookPtr);                              {!!.50}
  end;                                                         {!!.50}
  IsamExitCode(IFBPtr);
end;

Das ist der Code Der Procedure. Das Debuggen scheint sehr schwierig zu sein. Im Verlauf öffnen sich weitere 10Include Files in denen ca. 50 mal hin und her geswitched wird. :shock:

Zitat:

Zitat von Sir Rufo (Beitrag 1194361)

Ich habe mal alles überflüssige und evtl. Seiteneffekte erzeugende entfernt.
Schau mal, ob das funktioniert, wie gewünscht:

Delphi-Quellcode:

procedure TDemoForm.Button1Click( Sender : TObject );
var
  CurrentRow : Integer;
  A :       PersonDef;
  Current : PersonDef;
  RefNr :   LongInt;
  Key :     IsamKeyStr;
begin
  CurrentRow := 0;
  while ( CurrentRow < 100 ) and NextRecord( A, RefNr, 1, Key, true ) do
    begin
      BTGetRec( PersFB, RefNr, Current, False );
      Inc( CurrentRow );
    end;
end;

Danke für den Code, leider ändert es nichts. Bei meinem Problem handelt es sich um einen Zugriff auf eine Datenbank. Ich habe jetzt meine Datenbank nochmal mit einer Test DB ausgetauscht und kann diesen Fehler nicht mehr feststellen. Folglich liegt es an der Datenbank die ich habe. Das lässt das Problem allerdings noch aussichtsloser erscheinen.


Mfg, -187-


Edit: Ich bekomme auch eine Access Violation nach dem ersten Durchlauf der while Schleife. Ich versuche das mal zu debuggen.

[Sir Rufo]

Aber dann liefert NextRecord doch ein False zurück, was bedeutet, es gibt keine weiteren Records mehr, bzw. es werden keine weiteren gefunden.

Somit würde ich die Parameter, bzw. diese Funktion mal untersuchen

[-187-]

Zitat:

Zitat von Sir Rufo (Beitrag 1194363)

Aber dann liefert NextRecord doch ein False zurück, was bedeutet, es gibt keine weiteren Records mehr, bzw. es werden keine weiteren gefunden.

Somit würde ich die Parameter, bzw. diese Funktion mal untersuchen

Genau richtig! Der Code dazu sieht so aus:

Delphi-Quellcode:

function TDemoForm.NextRecord(var P : PersonDef;
                        var RefNr : LongInt;
                        KeyNr : Integer;
                        var Key : IsamKeyStr;
                        Next : Boolean) : Boolean;
begin
  NextRecord := False;

  BTNextKey(PersFB, KeyNr, RefNr, Key);
  if (IsamError = 10250) then Exit;

  NextRecord := True;
end;

Festgestellt habe ich das beim Versuch den zweiten Eintrag zu finden "PersFB" nicht mehr existiert. Was Die Access Violation erklären würde. Fragt sich nur warum. Und warum es bei der anderen DB funktioniert.

[-187-]

Also irgendwie läuft hier einiges schief. Bereits nach dem ersten Durchlauf der Schleife hat meine lokale Variable einen seltsamen Wert angenommen. Siehe Anhang!

[himitsu]

Laß dir mal den Wert dieser Variable in einer MessageBox oder Logdatei ausgeben.
Manchmal schafft es der Debugger einfach nicht den Wert richtigen anzuzeigen ... also sicherheitshalber, um zu sehn, ob es am Debugger liegt, oder doch am Code.

Und wenn es nicht der Debugger ist, dann wirst du wohl mal in diese Prozedur reinsehn müssen, was die nun falsch macht.

[-187-]

ShowMessage() liefert den selben Wert.

[-187-]

Sobald die Funktion NextPrevRecord durchgelaufen ist, enthält PersFB keinen Wert mehr. Allerdings ist der Wert vor dem letzten end der Funktion noch verfügbar, jedoch im begin Teil der while- Schleife nicht mehr. Woran kann das liegen? :roll:

Ich hab mal ein kleines Video gemacht weil's schwierig zu erklären wäre: (Leider ist die Qualität nicht so gut aber man kann es erkennen.)

http://videobam.com/EiILf

[Blup]

An welcher Stelle wird der Speicher für "PersFB" angefordert und erforderlichenfalls initialisiert, an welcher Stelle wieder freigegeben?

[DeddyH]

Zitat:

Zitat von Popov (Beitrag 1194354)

Ob man es prüft oder nicht ist so eine Sache. In Visual Basic hat man es geprüft. Ich bin von VB Programmieren ständig drauf hinweisen, dass ich da was vergessen habe. Wenn es in einer Sprache üblich ist, kann es in einer anderen nicht falsch sein, höchstens unnötig.

Um das nicht so stehen zu lassen (obwohl auch im Thread schon mehrfach darauf hingewiesen wurde): http://www.delphi-treff.de/tutorials...faengerfehler/
Zum Thema: da scheint es einen wilden Zeiger zu geben, siehe Blups Frage. Außer in der Assigned-Abfrage habe ich persönlich nichts von PersFB zu Gesicht bekommen, das erscheint mir komisch.

[Popov]

Zitat:

Zitat von DeddyH (Beitrag 1194386)

Um das nicht so stehen zu lassen ...

Bevor eine Staatsaffäre draus wird - ich hab selbst geschrieben, dass doppelt gemoppelt unnötig ist. Und was allgemein nicht falsch ist, kann auch nicht in Delphi falsch sein. Aber, andere Regeln, neue Regeln. Wenn bei Delphi direkt mit API arbeitet, dann gelten andere Regeln, nicht nur bei Boolean. Hier verlässt man Delphi und arbeitet mit dem Produkt einer anderen Sprache und das liefert u. U. für Boolean einen anderen Wert. Das muss man wissen. Das macht den Vergleich bei Delphi trotz dem nicht falsch. Wenn man mit Delphifunktionen arbeitet wird es also nie zu einem Problem kommen, bzw. ist es gehopst wie gesprungen. Vielmehr kann ein Vergleich beim Zusammenarbeit mit anderen Sprachen problematisch werden. Somit ist die Formulierung mit Falsch falsch. Es ist empfehlenswert drauf zu verzichten, da man sonst beim Arbeiten z. B. mit API dessen Boolean zuerst konvertieren muss, was sonst nicht nötig ist ;)

[-187-]

Zitat:

Zitat von Blup (Beitrag 1194383)

An welcher Stelle wird der Speicher für "PersFB" angefordert und erforderlichenfalls initialisiert, an welcher Stelle wieder freigegeben?

Form.Show() ruft InitDataBase (Funktion) auf. InitDataBase ruft OpenTheFile (Funktion) auf. In OpenTheFile steht:

Delphi-Quellcode:

BTOpenFileBlock (PersFB, FBlock, False, False, False, True);

BTOpenFileBlock sieht so aus:

Delphi-Quellcode:

procedure BTOpenFileBlock(var IFBPtr      : IsamFileBlockPtr;
                              FName       : IsamFileBlockName;
                              ReadOnly,
                              AllReadOnly,
                              Save,
                              Net         : Boolean);

Im Form Close wird diese Prozedur aufgerufen:

Delphi-Quellcode:

BTCloseFileBlock(PersFB);



procedure BTCloseFileBlock(var IFBPtr : IsamFileBlockPtr);
  {-Closes a fileblock}
begin
  IsamEntryCode(IFBPtr, NoOptions);
  if IsamOK then
    IsamCloseFileBlock(IFBPtr);
  IsamExitCode(Pointer (NotAFileBlockPtr));
end;

[Popov]

Eine kleine Frage. Vielleicht steht das auch irgendwo und ich habe es nur überlesen. Die Frage ist - funktioniert dein Code nicht so wie du es dir vorstellst oder interessiert es dich nur wieso Next False ist? Denn darauf kann es zwei verschiedenen Antworten geben.

[DeddyH]

Es scheint, als ob zwischen dem BTOpenFileBlock und dem BTCloseFileBlock der Pointer PersFB bzw. die dahinterstehenden Daten irgendwie verloren geht/gehen. Ein FreeMem oder dergleichen hast Du nicht eingebaut?

[-187-]

Zitat:

Zitat von Popov (Beitrag 1194394)

Eine kleine Frage. Vielleicht steht das auch irgendwo und ich habe es nur überlesen. Die Frage ist - funktioniert dein Code nicht so wie du es dir vorstellst oder interessiert es dich nur wieso Next False ist? Denn darauf kann es zwei verschiedenen Antworten geben.

Mein Code funktioniert nicht.

Zitat:

Zitat von DeddyH (Beitrag 1194407)

Es scheint, als ob zwischen dem BTOpenFileBlock und dem BTCloseFileBlock der Pointer PersFB bzw. die dahinterstehenden Daten irgendwie verloren geht/gehen. Ein FreeMem oder dergleichen hast Du nicht eingebaut?

Nein, hab ich nicht.


Edit: Ich habe in der Doku einen anderen Weg gefunden alle Einträge abzufragen und damit scheint es etwas besser zu klappen. Ich probier erstmal weiter, vielleicht hat sich das Problem hier erledigt.

[-187-]

Ok die anfänglichen Probleme des Zugriffs scheinen fürs Erste überwunden. Jedoch stell ich jetzt fest, dass ich seltsame Zeichen in den Datensätzen habe. Erst dachte ich das Delphi 2010 mit btreefiler nicht klar kommt und hab D7 installiert, jedoch hat das nichts verändert. Im Anhang mal ein Bild aus dem Debug Mode wie ein Datensatz beispielsweise aussieht. Jemand eine Idee?

[-187-]

Hmm bin eigentlich noch nicht weitergekommen. Das Problem ist, wenn ich die Werte der Datenbank in einem Memo Feld darstellen möchte, wird nur ein Teil des Wertes angezeigt da dieser "Null Terminated Characters" enthält und der Wert nach diesem Character abgeschnitten wird. Jedoch sind es nicht nur #0 Werte sondern auch Sonderzeichen die da eigentlich nicht hingehören.

Ich hab keine Idee. :|

[-187-]

Nach wiederholtem Lesen der Dokumentation hab ich festgestellt das ich die Struktur der DB ursprünglich falsch verstanden habe. Naja, jetzt funktioniert es und das Thema kann geschlossen werden.

Danke nochmals für eure Unterstützung.

-187-