Variablen werden überschrieben!?

[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 Next = true vergleicht oder einfach nur mit 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.

[Bummi]

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

[Sir Rufo]

Zitat von Bummi:

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

Sowas habe ich da auch im Kopf, evtl. noch ein Seiteneffekt von 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.

Zitat von 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;

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

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!

[DeddyH]

Zitat von Popov:

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 von DeddyH:

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