ftFmtMemo verliert Daten?!

[Richard Säger]

<P>Hallo allerseits,</P>

<P>ich habe in fünf Paradox 7 Tabellen Felder von Typ ftFmtMemo.
Das Feld wird immer in einer TDBRichEdit Komponente bearbeitet.
In 4 Fällen ohne Probleme, wie erwartet, nur in einem Fall gehen die Felddaten während der Methode TTable.Post verloren.</P>

<P>Ich prüfe den Wert von TableFeld.Value in der Methoden BeforPost und AfterPost, in BeforPost ist alles OK, in AfterPost (und in der Tabele) ist das Feld plötzlich leer.</P>

<P>An der TDBRichEdit Komponente kann es nicht liegen, die wird in allen anderen Fällen auch verwendet (ich benutze Frames), ausserdem habe ich versucht, die TDBRichEdit Komponente auch direkt einzusetzen.</P>

<P>Nach 6 Stunden bin ich jetzt am Ende, woran kann es liegen?</P>

<P>PS: Das ich nicht vergesse - Delphi 5 <g>.</P>

[Andreas Kosch]

Hallo,

verwenden alle Paradox-Tabellen (auch die problematische) einen Primärschlüssel? Wenn ja, unterscheidet sich sonst irgendwie der Aufbau der Tabellenstruktur?

Wenn das Problem auch dann auftritt, wenn in einem eigenen Testprogramm direkt über TDBRichEdit auf die Tabelle zugriffen wird, würde ich die Ursache zuerst in der Tabellenstruktur (Index, Eingabeprüfungen etc.) suchen

[Richard Säger]

<P>Hallo und danke für die schnelle Antwort,</P>

<P>alle Paradox-Tabellen verwenden einen Primärschlüssel.
Die Tabellenstruktur ist in allen Fällen relativ einfach: Primärschlüssel Integer,
dann ein Paar Daten wie Beschreibung, Preis usw., und eben Bestelltext in einem ftFmtMemo Feld.
Die problematische Tabelle hat als einzige den Primärschlüssel aus 4 Integer-Felder,
sonst kann ich nichts finden.</P>

<P>In einem Programm, das nur aus einem Formular besteht und keine andere Tabellen öffnet,
kann ich das ftFmtMemo Feld speichern. Dann reicht es allerdings der gleiche Datensatz
im "echten" Programm ohne Änderungen zu speichern, und der Text verschwindet während der
Post-Methode ohne Fehlermeldung wieder. Alle andere Felder werden ordnungsgemäß gespeichert.
Eingabeprüfungen haben offensichtlich keinen Einfluss darauf, ich habe nur wenige
und die habe ich auch noch gelöscht.</P>

<P>Ich schaue mir den Wert von dem Feld im Debugger während BeforPost, da ist es OK,
und während AfterPost, da ist er ein Leerstring.</P>

<P>Jetzt habe ich aber etwas ganz verrücktes ausprobiert:
Mit der Datenbankoberfläche habe ich in der Tabelle ein weiteres ftFmtMemo Feld angelegt.
Danach konnte ich Daten in <B>beiden</B> Feldern problemlos speichern. Anschließend habe ich
das zusätzliche Feld wieder gelöscht und ... <B>ich kann in dem ursprünglichen Feld weiter
speichern, alles ist in Ordnung!</B></P>

<P>Was soll das? Die Tabelle wurde doch in einem Delphi-Programm angelegt und anschließend
wurden Daten mit BatchMove aus dBase Dateien übernommen. Alle Datenfelder ausser diesem waren
in Ordnung. Ich verstehe das nicht.</P&gt

[Andreas Kosch]

Hallo,

ich gehe einmal davon aus, das sich dieser Fehler nicht reproduzieren lässt. Wenn noch eine alte Sicherungskopie der "fehlerhaften" Tabelle am Lager ist, könnte man mit <b>TUtility</b> die Tabelle auf Strukturbeschädigungen untersuchen. Wird kein Fehler gemeldet, würde ich außerdem zum Test eine neue Tabelle anlegen, wobei die Struktur von der fehlerhaften Tabelle eingelesen wird. Tritt dann der Fehler immer noch auf? Wenn nicht, war offensichtlich die Tabellenstruktur beschädigt

[Richard Säger]

<p>Hallo Andreas,</p>

<p>ich habe alles gleich am Anfang mit einer neu angelegten leeren Tabelle getestet. Die Tabelle habe ich mit der Datenbankoberfläche angelegt. Da hat es auch nicht funktioniert. Jetzt suche ich ein workaround <g>.</p&gt