Komischer Datenbankeffekt

[sko1]

Hallo,

ein besserer Threadtitel fiel mir nicht ein, ich debugge seit Stunden und komme nicht weiter:

Folgender Ablauf:
Es gibt eine global deklarierte Klasse, welche unter anderem ein Array beinhaltet.
Dieses wird beim Erstellen der Klasse mit SetLength eingestellt und gefüllt.

Nun speichere ich in einer SQLite-DB folgendermaßen:

- Tabellen anlegen
- Tabellen füllen

Jedes Tabelle füllen erzeugt eine Connection zur DB, füllt die Tabelle und Destroid diese Connection wieder.
Das Füllen der ersten Tabellen funktioniert, bei der dritten Tabelle ist beim .Connected := true der FDConnection plötzlich das Array leer (High()=-1)!!!!!

Da ich absolut keinen Zusammenhang sehe, das Tabelle füllen bei den ersten Malen funktioniert, bin ich mit meinem Latein am Ende!

Hat irgend jemand eine Idee wo ich ansetzen könnte?

Ciao
Stefan

[sakura]

Das eine hat sehr wahrscheinlich nichts mit dem anderen zu tun... Aber ohne den Source Code wird das hier ein Jahrmarktsraten...

...:cat:...

[TiGü]

Guck dir mal das Tutorial an:
http://www.delphipraxis.net/41047-tu...ortgeschr.html

Speziell der Abschnitt Datenhaltepunkte.
Damit kannst du eventuell herausfinden, wann und warum dein Array verändert wird.

[sko1]

Jetzt habe ich mal etwas entdeckt, aber warum das so ist, vielleicht weiß jemand etwas:

Den kompletten (sehr umfangreichen) Code kann ich leider nicht zur Verfügung stellen, ich versuche mal zu skizzieren:

global deklariert:

Delphi-Quellcode:

type
  TFeld = record
    Eintrag1: integer;
    Eintrag2: integer;
    ...
  end;

type
  TSettings = record
    Eintrag1: integer;
    Eintrag2: integer;
    Stream1 : TMemoryStream;
    Stream2 : TMemoryStream;
    ...
  end;

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

Zum Schreiben in die Datenbank folgender Codeschnipsel:

Delphi-Quellcode:

    Vorlage.Settings.Stream1.Position := 0;
    TBlobfield(FDQuery.FieldByName('Stream1'))
          .LoadFromStream(Vorlage.Settings.Stream1);
      end;

und mit dieser Zeile LoadFromStream... ist das Array of TFeld leer!

Kann jemand damit etwas anfangen?

Ciao
Stefan

[sakura]

Bist Du Dir sicher, dass das Feld als TBlobfield erstellt wurde? Überprüfe mal den Datentyp.

...:cat:...

[sko1]

ich denke schon, das Speichern / Laden der Streams hat ja vorher funktioniert, jetzt möchte ich zusätzlich das Array speichern und es wird dabei zerstört!

Delphi-Quellcode:

SQL.TEXT := 'CREATE TABLE IF NOT EXISTS [Vorlage] (Seite INTEGER, Stream1 BLOB, .......);';

Ciao
Stefan

[sakura]

Zitat:

Zitat von sakura (Beitrag 1387067)

Bist Du Dir sicher

...

Zitat:

Zitat von sko1 (Beitrag 1387068)

ich denke schon

Denken ist nicht überprüfen. ;-)

Unabhängig davon, es ist wahrscheinlich, dass der Fehler schon an anderer Stelle auftritt und durch einen Überlauf verursacht wurde. Wenn Du die Reihenfolge der Deklarationen in Deiner Klasse änderst, dann würdest Du evtl. den Inhalt einer anderen Variable zerstören.

...:cat:...

[sko1]

Wie bekomme ich solch einen Überlauf raus?
Selbst wenn ich den Stream auf Platte zwischenkopiere und daraus ins Datenbankfeld schreibe ist das Array futsch!

Delphi-Quellcode:

    Vorlage.Settings.Stream1.Position := 0;
    Vorlage.Settings.Stream1.SaveToFile('c:\temp\xxx');
    TBlobfield(FDQuery.FieldByName('Stream1')).LoadFromFile('c:\temp\xxx');

und zwar genau in dem Moment TBlobfield(FDQuery.FieldByName('Stream1')).LoadFro mFile

Ciao
Stefan

[TiGü]

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

[sko1]

Ich habe umgebaut, es wird noch verwirrender:

Delphi-Quellcode:

 
   //umkopieren in anderen Stream
   ms:=TMemoryStream.Create();
   ms.Position := 0;
   ms.CopyFrom(Vorlage.Settings.Stream1, Vorlage.Settings.Stream1.size);
   ...

schon beim Kopieren in ms ist das Array Vorlage.Felder, was damit ja eigentlich überhaupt nichts zu tun hat, leer!

Ciao
Stefan

[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

[TiGü]

Zitat:

Zitat von sko1 (Beitrag 1387312)

Wie könnte man nun noch weiterkommen?

Besteht das Problem jetzt nur noch darin, dass auf einen (1!) Entwicklungsrechner merkwürdige Phänomene auftreten?

[sko1]

Gute Frage!

Ich traue dem Radstudio jetzt nicht mehr über den Weg!
Ich muss doch ein Projekt egal auf welchem Rechner zum gleichen Ergebnis kompilieren können!

Wie bekomme ich die kompletten RAD-Studio-Einstellungen vom Notebook auf den großen Rechner?

Ciao
Stefan

[TiGü]

Laptop virtualisieren und dann nur noch mit der VM entwickeln. 8-) :lol:

[Bernhard Geyer]

Welche Version ist betroffen?
Gabs da nicht eine mit einem kapitalen Fehler bei offenen Arrays (Array of TFeld)?

[hoika]

Hallo,
ich würde gern mal den kompletten DB-Code um das FieldByName sehen.
Denn muss das nicht ParamByName heißen?

Und bist du sicher, dass die auf beiden Rechnern mit der gleichen, identischen DB arbeitest?

[hoika]

Hallo,
fehlt vielleicht irgendwo ein TXStream.Create?

[sko1]

So, endlich kann ich positive Rückmeldung geben!

Die Datenbank war nicht das eigentliche Problem, wie FastMM4 mir mitgeteilt hat.
Problemursache war das Array of TSonderfeld wobei

Delphi-Quellcode:

type
  TSonderfeld = record
    Feld1: integer;
    Feld2: integer;
    ...
  end;

ein primitiver Record war.
Diesen habe ich jetzt in eine Klasse gepackt und benutze nun ein Array dieser Klasse.

Warum ein Array aus Records hier Probleme gemacht hat (es gibt auch weitere solche Arrays ohne negative Effekte) und die Probleme nun als Klassen-Array beseitigt sind, entzieht sich allerdings meiner Kenntnis...

Ich werde auf jeden Fall vorsorglich auch die anderen Records als Klassen deklarieren!

Ciao
Stefan

[TigerLilly]

Aber das Problem ist jetzt größer geworden! Du weißt nicht, was das Problem war, aber es taucht nicht mehr auf. Das ist ganz übel. Fehler vermeiden != Fehler beheben.

So wie du das beschreibst, gibt es irgendwo Probleme mit nicht oder bereits initialisierten Objekten. Deswegen ist das Problem auch nicht gut reproduzierbar.

Deshalb: Erkenne den Fehler!

[p80286]

Zitat:

Zitat von TigerLilly (Beitrag 1387550)

So wie du das beschreibst, gibt es irgendwo Probleme mit nicht oder bereits initialisierten Objekten. Deswegen ist das Problem auch nicht gut reproduzierbar.

Eigentlich hat Sakura bereits in #7 darauf hingewiesen, aber diese Ursache scheint per Definitionem unmöglich zu sein.

Gruß
K-H

[TigerLilly]

Zitat:

Zitat von p80286 (Beitrag 1387554)

Eigentlich hat Sakura bereits in #7 darauf hingewiesen

Ich wollte mich keineswegs mit den Erkenntnissen von sakuara-san schmücken. Mir ging es auch weniger darum, was das Problem jetzt wirklich ist, sondern, dass "es taucht nicht mehr auf" und "es ist behoben" nicht das gleiche und schon gar nicht dasselbe sind.

[p80286]

Da hast Du mich falsch verstanden, mir ging es nicht um "fremde Federn" eher um Wiederholung die in diesem Falle leider vergebens ist. Ich stimme mit Deinen Folgerungen vollkommen überein.

Gruß
K-H

[TigerLilly]

:thumb: