Zeoslib + Sqlite + Viel Text

[mcbain]

Hallo,
ich verwende Sqlite mit den Zeos und DXE2.
Mein Problem ist, dass ein Text-Feld aus der Datenbank nicht komplett ausgelesen wird.
Ich habe mit meiner Tabelle ein DBGrid und ein DBMEmo verlinkt, allerdings werden mir immer nur 255 Zeichen in dem DBMemo angezeigt, obwohl mindestens 1200 Zeichen in dem Feld der Datenbank stehen.
Ich habe auch bereits die DisplayWidth erhöht, jedoch ändert sich nichts.
Wenn ich die Spalten im ComponentEditor meiner Table Komponente automatisch hinzufügen lasse, erkennt der Editor das Text Feld der Datenbank als StringField, allerdings müsste er wohl eher ein Memofield erkennen, da ich die Länge des strings in der Datenbank ja nicht wissen kann.

Kann mir hier jemand weiterhelfen bitte?
Vielen Dank.
Gruß
MC

[EgonHugeist]

Zeos kürzt nicht Typ-definierte strings (z.B. VARCHAR()) auf 255 Zeichen.

Declariere das Feld als TEXT und das Memo wird vollständig gelesen...

Änderungen kommen erst mit 7.2, da es sich um Alltime-Code handelt.

Gruß, Michael

[mcbain]

Vielen Dank für die Antwort.
Wo meinst du soll ich das Feld als Text deklarieren? In der Datenbank ist das Feld als TEXT Feld erstellt.
Das Problem liegt auch daran, dass z.B. bei zTable.FieldbyName('meineSpalte').AsString := 'mein laaanger Text....'; nur 255 Zeichen in die Datenbank gespeichert werden.

Gruß
mc

[mcbain]

Ich habe rausgefunden, dass das TEXT-Feld einer Virtuellen SQLite Tabelle nicht gleich dem TEXT-Feld eine normalen SQLite Tabelle in Delphi erkannt wird. Das 1. erkennt er richtig als Memo Feld, aber das 2. wird immer als normaler String erkannt.
Hat noch jemand ne Idee was ich machen könnte?

Danke.
Gruß
Mc

[Bernhard Geyer]

Zitat von EgonHugeist:

Zeos kürzt nicht Typ-definierte strings (z.B. VARCHAR()) auf 255 Zeichen.

Was ist das für eine bescheuerte Logik die Beschränkung eines DBMS (in einer alten Version) auf alle DB's anzuwenden?

Zitat von EgonHugeist:

Declariere das Feld als TEXT und das Memo wird vollständig gelesen...

TEXT-Felder haben bei fast allen DBs einige Nachteile gegenüber varchar-Feldern.
Das dürfte nur für wenige Einsatzfälle eine sinnvolle DB-Anpassung darstellen.

[mcbain]

Ich erläutere mein Problem mal etwas genauer:
Ich arbeite gerade an einem Projekt, in dem ich Volltextsuche benötige.
Das Ganze soll allerdings nur lokal im kleinen Rahmen stattfinden, deshalb ist SQLite völlig ausreichend.
Aber da es durchaus mal sinnvoll sein kann, zu sehen, was mein Programm als Volltext abgespeichert hat, würde ich gerne den Text in einem MEmo ausgeben lassen. Nur leider werden mir ja immer nur 255 Zeichen angezeigt...

Alles andere Funktioniert bereits recht zuverlässig mit den ZEOS, nur bekomme ich das mit dem String nicht in den Griff...

Wenn jemand also noch einen Tip hat, bzw. mir die Codestelle bei den ZEOS nennt, die ich man anpassen müsste, damit mir der gesamte String gespeichert und gelesen wird, wäre ich sehr dankbar.

Vielen Dank.
Gruß
mc

[EgonHugeist]

Zitat von mcbain:

Ich habe rausgefunden, dass das TEXT-Feld einer Virtuellen SQLite Tabelle nicht gleich dem TEXT-Feld eine normalen SQLite Tabelle in Delphi erkannt wird. Das 1. erkennt er richtig als Memo Feld, aber das 2. wird immer als normaler String erkannt.
Hat noch jemand ne Idee was ich machen könnte?
Mc

..."

Gib mir etwas zum Arbeiten und ich kann da ein Fix bereitstellen. Außerdem müßte ich die Zeos-Version wissen.

Zitat von Bernhard Geyer:

Zitat von EgonHugeist:

Zeos kürzt nicht Typ-definierte strings (z.B. VARCHAR()) auf 255 Zeichen.

Was ist das für eine bescheuerte Logik die Beschränkung eines DBMS (in einer alten Version) auf alle DB's anzuwenden?

Zitat von EgonHugeist:

Declariere das Feld als TEXT und das Memo wird vollständig gelesen...

TEXT-Felder haben bei fast allen DBs einige Nachteile gegenüber varchar-Feldern.
Das dürfte nur für wenige Einsatzfälle eine sinnvolle DB-Anpassung darstellen.

LOL, ja Hand-Shake. Hmm ich hab's nicht so geschrieben und scheint mir aus URALT-Zeiten zu kommen (String=ShortString). Jedoch kenne ich nur 2 DBMS die undefnierte Längen unterstützen: PostgreSQL und SQLite. Mehr? Für PostgreSQL hab ich das schon geändert seit 7.1! SQLite steht noch aus und da wir ein Behavior-Freeze seit 7.1-Beta haben, kommt das Patch erst mit 7.2. Ich kann nicht alles gleichzeitig machen, Berhnardt. Alles geschieht in meiner Freizeit und kostet nix.

[haentschman]

Zitat:

Alles geschieht in meiner Freizeit und kostet nix.

...dafür an dieser Stelle mal Dank und Respekt.

[Bernhard Geyer]

Zitat von EgonHugeist:

LOL, ja Hand-Shake. Hmm ich hab's nicht so geschrieben und scheint mir aus URALT-Zeiten zu kommen (String=ShortString).

Müsste es nicht eher aus der Prä-MySQL_5.0.3-Zeit stammen (Siehe: http://dev.mysql.com/doc/refman/5.0/en/char.html)
Wie alt ist den Zeos? 18 Jahre (also mit D1 erschienen).

Zitat von EgonHugeist:

Jedoch kenne ich nur 2 DBMS die undefnierte Längen unterstützen: PostgreSQL und SQLite. Mehr? Für PostgreSQL hab ich das schon geändert seit 7.1! SQLite steht noch aus und da wir ein Behavior-Freeze seit 7.1-Beta haben, kommt das Patch erst mit 7.2.

Es geht mir darum das man nicht einfach varchar durch text ersetzen kann. Performance und SQL-Technisch sind hier einige unterschiede.

[EgonHugeist]

Guten Morgen,

Zitat von Bernhard Geyer:

Müsste es nicht eher aus der Prä-MySQL_5.0.3-Zeit stammen (Siehe: http://dev.mysql.com/doc/refman/5.0/en/char.html)
Wie alt ist den Zeos? 18 Jahre (also mit D1 erschienen).

Hmm ja/jain, k.A. Also SQLite folgt keinen konkreten Feld-Typ Definitionen und prüft diese auch nicht. Du kannst das Feld auch ohne Typ deklarieren, oder den Typ als "XYZ" beschreiben. Schreibe 10x Integer, SQLite gibt dir einen Int64 Type für die Column zurück. Nun schreibe einen String und schwups haben wir einen String Typen. Zeos ging einfach bei den String-basierenden Result-Sets (e.g. MySQL(nicht Real-Prepared), PostgreSQL, SQLite) davon aus, alle unbekannten Typen als VARCHAR(255) zu handeln. Tatsache würde ich auch behaupten, daß wohl die Performance der Grund des Übels ist.

Wir sind uns einig: TEXT/CLOB... Typen sollten so weit, wie möglich vermieden werden, da diese zu Lasten der Performance gehen.

@mcbain

Definiere das Feld als VARCHAR(1700) und es rockt wieder..