TDBMemo zeigt Zeilenumbrüche nicht

[knownix]

Hallo,

beim Versuch mehrzeiligen (mit <Return> getrennten) Text aus einer SQLite3-DB in TDBMemo Komponenten darzustellen, gehen die Zeilenumbrüche verloren, d.h. die Textzeilen werden ohne Leerzeichen aneinandergefügt. TDBText zeigt die Inhalte dagegen richtig umgebrochen an. Die Inhalte der DB-Text-Felder scheinen korrekt zu sein. - Füge ich die fehlenden Returns in TDBMemo ein und schreibe sie in die DB zurück, entstehen in externen DB-Betrachtern Leerzeilen (d.h. 2x CR/LF). Demnach erscheinen die ursprünglichen CR/LFs nur in der Anzeige nicht. Ist das normal oder mache ich etwas falsch?

Im Voraus vielen Dank!
Gruß knownix

[Christian]

Das scheint an deinen Datenzugriffskomponenten zu liegen, mit Zeos hab ich das Problem jedenfalls nicht.

[knownix]

Vielen Dank für den Hinweis! Ich benutze die mitgelieferten Data-Access-Komponenten (SQLite3Dataset und Datasource) und auch die entsprechenden Data Controls. Dachte ehrlich gesagt, die ZEOS-Komponenten seien für meine (einfachen) Zwecke unnötig. Hm, da werde ich dann wohl doch 'umsteigen' müssen...

Gruß knownix

[Christian]

Mit dem SQLite3 Komponenten hab ich sehr schlechte Erfahrungen gemacht. Aber SQLdb sollte mittlerweile auch recht stabil sein.

[knownix]

Äh, ich hänge noch ein wenig beim Installieren der ZEOS 6.6.6.-Komponenten. Ist wohl mal wieder die Groß- und Kleinschreibung... Momentchen.

[knownix]

Da bin ich wieder. Zuerst die beste Nachricht: Die Zeos-Komponenten sind toll! DANKE! Also DER Umstieg hat sich wirklich gelohnt! Auch für mein Problem. Nicht etwa weil's weg war, sondern weil's weiter auftrat. Zweite gute Nachricht: Mit dem TDBMemo und den Datenzugriffskomponenten ist alles in Ordnung. Auch mit den mitgelieferten. (Ich ziehe meine dümmliche Frage hiermit mit dem Ausdruck tiefsten Bedauerns zurück!)
Es lag natürlich doch an meiner SQLite-DB. War aber erst durch Hinzuziehung eines HEX-Editors zu finden. Beim Hin- und Herkonvertieren meines alten Delphi2/4-DB-Projekts muss ich einen Fehler gemacht haben, der dazu führte, dass von den CR/LFs (0D0A) in den Memofeldern nur noch LF (0A) übrigblieb. Keine Ahnung wieso. Wenn man die (unsichtbaren) LFs in den Memofeldern löscht und durch ein <Return> (0D0A) ersetzt, ist alles ok. Prima, jetzt muss ich das nur noch für die genau 36756 Datensätze mit den je 6 Memofeldern erledigen, damit die Galoppeldatenbank meiner 'kleinen' Schwester wieder läuft (oder vorzugsweise eine kleine Routine dafür schreiben...)
Herzlichen Dank und Gruß an alle, die mitgegrübelt haben, speziell Christian!
knownix
(Der Name ist Programm!)

[Christian]

Ich erinner mich grau das das Memo unterschiedlich ragieren kann auf die Lineendings. Ist jetzt wirklich ins Blaue hinein, da ich gerad keine zeit hab nachzuschaun aber schau dir mal die properties des Memo an, vllt sogar auch TMemo oder TStrings es kann durchaus sein das DBMemo das im moment nicht erbt. ich meine man konnte irgendwo einstellen was für zeilenenden akzeptiert werden. Vllt musst du nichtmal was konvertieren.

[m.fuchs]

Ich erinner mich grau das das Memo unterschiedlich ragieren kann auf die Lineendings.

Die Einstellung hängt an den Lines (TStrings). Dort gibt es eine Property TextLineBreakStyle die man auf tlbsLF, tlbsCRLF oder tlbsCR setzen kann. Zumindest beim normalen Memo funktioniert das so.

[knownix]

Oh wow, DAS ist ja elegant! Die Objekthierarchie habe ich glatt vergessen. In der rtl-Referenz habe ich's nach euren Hinweisen auch gefunden, wäre aber alleine nie darauf gekommen.
Beim Ausprobieren wurde mir dann aber klar, dass -wenn die DB weiter benutzt wird- die Daten inkonsistent werden könnten (Neue Memo-Einträge womöglich mit CR/LF, alte nur LF). Dann fiel mir wieder der HEX-Editor ein. Einer meiner früheren Paradox-Konvertierungsversuche war eine unkritische CSV-Datei. Ersetze alle 0A durch 0D0A, anschließend falls fehlerhafte 0D0D0A entstanden wären (wo schon ein 'richtiges' CR/LF stand) diese wieder durch 0D0A rückersetzen. Voilà. - Ich weiß, das ist völlig dilettantisch! Andererseits stimmen jetzt Daten und Ansicht endlich wieder überein und schnell gings auch noch.
Trotzdem vielen, herzlichen Dank!!! Euer Ansatz ist natürlich viel systemkonformer, schöner und lehrreicher. Andererseits versteht ihr vielleicht, dass ich meinen dummen Paradox-Auslesefehler real aus der Welt schaffen wollte (und nicht 'nur' in einer korrigierten Ansicht).

Nochmals Danke für eure Mühe!
Gruß knownix

[Socke]

Beim Ausprobieren wurde mir dann aber klar, dass -wenn die DB weiter benutzt wird- die Daten inkonsistent werden könnten (Neue Memo-Einträge womöglich mit CR/LF, alte nur LF).
[...]
Euer Ansatz ist natürlich viel systemkonformer, schöner und lehrreicher. Andererseits versteht ihr vielleicht, dass ich meinen dummen Paradox-Auslesefehler real aus der Welt schaffen wollte (und nicht 'nur' in einer korrigierten Ansicht).

Eine konsitente Datenhaltung ist viel mehr Wert als eine konstistente Darstellung; es ist nämlich viel einfacher letzteres zu erreichen, wenn ersteres schon gegeben ist.
Wenn du aber nicht konsistente Daten hast -- oder noch besser: gleiche Daten in verschieden Datentypen oder -formaten -- ist das nicht nur mit der Anzeige ziemlich bescheuert.

[knownix]

Ähem, es ist natürlich auch schwierig, jemandem einen vernünftigen Rat zu geben, der die falsche Frage stellt, sein eigenes Problem nicht kennt und dann noch die notwendigen Informationen (konvertierte Delphi-Paradox-DB mit viel zu vielen Datensätzen, die nicht nur angesehen, sondern auch noch weiter benutzt werden soll) nur scheibchenweise rüberbringt. Hoffe, mein grandioser Forum-Fehlstart gerät irgendwann noch mal in Vergessenheit. Bin ja sonst kein sonderlicher Freund von Smileys, aber in diesem Fall:

Gruß K.

[MmVisual]

Bei so vielen Datensätzen und Paradox, da würde ich mir ernsthaft mal überlegen die in einen SQL Server zu bekommen.
Jetzt wo Du Zeos verwendest, Zeos kann problemlos SQLite, MySQL und PostgreSQL. Ich habe ein Programm geschrieben, das alle 3 DB's unterstützt, danke Zeos ging das super einfach. (bis auf ein paar wenige SQL Abfragen, die aber auch sehr spezielle Verschachtelungen drin haben, die ich entsprechend umschalten muss)

[knownix]

Was die Server-DBs angeht, so habe ich das etliches durchprobiert (zuletzt Qt/PostgreSQL), ständig auf der Suche etwas ähnlich Leichtgängigen wie meinem alten Delphi2/4. Vor 14 Tagen geriet ich dann zufällig an Lazarus. (Happy End!) Zuerst dachte ich an Postgre oder Firebird, aber für meine 'Endkundin' muss alles unkaputtbar und so einfach wie möglich sein. (Komplette DB in einer Datei und flexible, fehlertolerante Datentypen, das hört sich wartungsfreundlich an.) Außerdem ist der Speicherverbrauch trotz der Datenmenge bisher geradezu lächerlich klein und die Performance scheint immerhin noch akzeptabel. Wenn sich das bei komplexen SQL-Statements ändern sollte, hält sich der Aufwand beim Umstieg auf eine andere DB (wie von dir vorgeschlagen, MmVisual) dank Zeos dann hoffentlich in Grenzen. Bin also bisher eher noch am Rumspielen als entschieden, gestern war ich ja noch nicht mal sicher, ob ich die Daten überhaupt habe retten können...
Gruß knownix

[MmVisual]

>> ob ich die Daten überhaupt habe retten können...
Du hast doch sicher ein ZIP-Archiv von den alten Origionaldaten.

Wenn es eine Datei sein soll in der alles einfach zu handhaben ist dann am besten SQLite. Ich weiß jetzt natürlich nicht wie viele User gleichzeitig die Daten nutzen, aber ich gehe mal von einem User aus.

Ansonsten hier: http://www.usbwebserver.net/en/" onclick="window.open(this.href);return false;
kann ein MySQL Server geladen werden, der lokal läuft. Alles in einem Verzeichnis drin, das man einfach nur kopiert und sogar mit USB-Stick von jedem Rechner aus startet.

[Socke]

Zuerst dachte ich an Postgre oder Firebird, aber für meine 'Endkundin' muss alles unkaputtbar und so einfach wie möglich sein. (Komplette DB in einer Datei und flexible, fehlertolerante Datentypen, das hört sich wartungsfreundlich an.)

Alles in einer Datei kann man wunderbar mit Microsoft Access realisieren. Da hat man in einer Datei die Datenbank und die gesamte Programmlogik. Die Programmlogik in VBA dann aber zu realisieren ist keine gute Idee und eine Migration auf andere Datenbanksystem schließt sich praktisch aus. Performant ist das ganze auch nur bis zu sehr wenigen gleichzeitigen Benutzern.

Flexible und "fehlertolerante" Datentypen liefert SQLite gleich mit; da sind Datentypen nur eine Präferenz, was in einer Spalte gespeichert werden könnte. Es liegt tatsächlich keine reale Typbindung vor.
Wenn die Anwendung in Pascal realisiert wird, hat das aber keinen wirklichen Vorteil, da Pascal seit jeher eine starke Typstrenge besitzt. Inwiefern ZEOS und SQLdb als Abstraktionsschicht zwischen den Datenbank- und Pascal-Datentypen umsetzten, sollte auch beachtet werden.
Trotzdem muss man ein typsicheres Datenmodell entwickeln, damit die Migration auf andere Datenbanken leichter fällt. Hier bietet SQLite den Vorteil, dass es auch andere SQL-Dialekte versteht und in der SQL-Syntax recht tolerant ist (vor allem, was die verschiedenen Klammern und Anführungszeichen angeht).

Hört sich jetzt vielleicht ein wenig wie Werbung dafür an, aber persönlich habe ich nur mit SQLite und Access entwickelt; es dürfte wohl klar sein, welche Datenbank ich bevorzuge...