Komischer Datenbankeffekt

[sko1]

Zitat:

Datenhaltepunkt...hallo? Irgendwer? Beitrag Nummer 3?

ich debugge ja, was willst Du mir denn eigentlich damit sagen?

Ciao
Stefan

[TiGü]

Zitat:

Zitat von sko1 (Beitrag 1387075)

Zitat:

Datenhaltepunkt...hallo? Irgendwer? Beitrag Nummer 3?

ich debugge ja, was willst Du mir denn eigentlich damit sagen?

Ciao
Stefan

Hast du das Tutorial angeschaut?
Ein Datenhaltepunkt ist kein normaler roter Haltepunkt!
Du kannst explizit auf dein Array einen Datenhaltepunkt setzen und das Programm hält an, wenn auf der Adresse geschrieben wird.
Anhand des Call Stacks wirst du dann sicherlich schlauer.

[sko1]

Leider macht mich das überhaupt nicht schlauer, nur dümmer ;-)

Ich habe jetzt die Memorystreams in den Settings durch Strings ersetzt, welche ich an den entsprechenden Stellen dann wieder in einen Stream lade oder den Stream in String konvertiere.
Das Array bleibt ganz auch während des Wegschreibens in die Datenbank (FDQuery.fieldbyname('...').asstring aber dann beim FDQuery.Post ist das Array wieder weg!

Das kann doch alles nicht wahr sein!

Kommentiere ich das Schreiben dieser langen Strings aus ist nach Post alles noch in Ordnumg!

So langsam komme ich zu dem Eindruck, dass die FDQuery irgendwelche Probleme mit langen Feldinhalten hat?

Nur wie komme ich jetzt weiter?

Ciao
Stefan

[TiGü]

Zitat:

Zitat von sko1 (Beitrag 1387083)

Leider macht mich das überhaupt nicht schlauer, nur dümmer ;-)

Wenn du nicht genau verstanden hast wie es geht, dann frage doch einfach nach?!

Guck mal bitte hier ab Minute 31:30:
https://www.youtube.com/watch?v=eqs27gB7Zms

Zitat:

Zitat von sko1 (Beitrag 1387083)

Nur wie komme ich jetzt weiter?

Probiere mal folgendes.

Mache aus:

Delphi-Quellcode:

type
  TVorlage = class
  private
  public
    Filename: string;
    Settings: TSettings;
    Felder : Array of TFeld;

Jenes:

Delphi-Quellcode:

TWorkaround = class
public
  Felder : Array of TFeld;
end;

type
  TVorlage = class
  private
  public
    Filename: string;
    Settings: TSettings;
    FelderPerWorkaround :TWorkaround
...
  function GetFelder: Array of TFeld; 
...
function TVorlage.GetFelder: Array of TFeld;
begin
  Result := FelderPerWorkaround.Felder; 
end;

Das Array also in einer inneren Klasse "verstecken".

[sko1]

Danke für den Tip, werde ich sofort versuchen umzusetzen!

Inzwischen habe ich was ganz witziges entdeckt:

Vor dem Datenbankhandling erzeuge ich ein zweites Feldarray und fülle dieses aus der Vorlage.

Jetzt wird beim Datenbankschreiben das Originalarray nicht mehr zerstört!
Ich dachte als Würg-around dieses dann am Ende zurückzuschreiben...
Ist aber gar nicht notwendig!

Ich verstehe so langsam die Welt nicht mehr!

Ciao
Stefan

[sko1]

funktioniert nicht, "Bezeichner erwartet aber "Array" gefunden...

Delphi-Quellcode:

function GetFelder(): Array of TFeld;

Ciao
Stefan

[TiGü]

Zitat:

Zitat von sko1 (Beitrag 1387095)

funktioniert nicht, "Bezeichner erwartet aber "Array" gefunden...

Delphi-Quellcode:

function GetFelder(): Array of TFeld;

Delphi-Quellcode:

  TMeineKrassenFelder = Array of TFeld;  

function GetFelder(): TMeineKrassenFelder;

[sko1]

Danke, hatte ich inzwischen auch gefunden...

Leider ist das jetzt mit dem Testen so eine Sache, an hunderten Stellen im Programm greife ich auf dieses Array zu, die muss ich jetzt alle erst mal auf den Workaround umbauen und diese Miniklasse auch dafür entsprechend erweitern...

Ich überlege ob ich alles, was da so noch verwendet wird, in eine extra Klasse auslagere, wer weiß ob es demnächst nicht auch noch andere Arrays "zerlegt"?

Was ich wie gesagt gar nicht verstehe, der alleinige Zugriff auf das Array vor dem Datenbankhandling bewahrt es vor der Zerstörung durch dieses....

Ciao
Stefan

[TiGü]

Zitat:

Zitat von sko1 (Beitrag 1387101)

Was ich wie gesagt gar nicht verstehe, der alleinige Zugriff auf das Array vor dem Datenbankhandling bewahrt es vor der Zerstörung durch dieses....

Sagt dir der Begriff FastMM etwas?
FullDebugMode mit externer FastMM-DLL?
https://github.com/pleriche/FastMM4

Das würde ich mal auf deine Anwendung loslassen.
Lesestoff:
http://delphibistro.com/?p=186
https://stackoverflow.com/questions/...om-fastmm?rq=1

(mal gucken wann der erste Schlaubi Schlumpf um die Ecke kommt und sagt: "FastMM ist seit Delphi ElfDrölf integriert" - leider ist das sehr rudimentär und hilft nur begrenzt beim Suchen solcher Fehler)

[sko1]

So, ich melde mich mal wieder...

Das verstecken in einer kleinen Klasse hat nichts gebracht, hinzu kommt dass das beschriebene Phänomen nicht mehr auftritt wenn ich den identischen Code auf dem Notebook (mit identischem RAD Studio) debugge!

Wie könnte man nun noch weiterkommen?

Ciao
Stefan