Zeoslib + Sqlite + Viel Text

[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..

[mcbain]

Vielen Dank.
Ich werde heute Abend nachsehen, welche Zeos Version ich verwende.
Für einen Fix wäre ich dir natürlich sehr dankbar.
In der zwischenzeit setze ich die Länge des Varchar Feldes, wie erwähnt, höher.

Gruß
mc

[mcbain]

Selbst, wenn ich die Feldgröße des strings in Delphi - wie von EgonHugeist beschrieben - auf 1700 hochdrehe, bekomme ich nicht alle Zeichen dargestellt.
Oder meintest du ich solle in der DB aus dem TEXT-Feld ein Varchar Feld machen?

Meine Zeos Version ist übrigens die 7.0.4-stable mit Delphi XE2.

Gruß
mc

[Klaus01]

.. gut bei XE2 entsprechen ein Zeichen/Character - 2 Byte (wg. Unicode).

Grüße
Klaus

[EgonHugeist]

Zitat von Klaus01:

.. gut bei XE2 entsprechen ein Zeichen/Character - 2 Byte (wg. Unicode).

Ne, ne laß mal. Das macht Zeos automatisch. Varchar(100) enstpicht 100x4 Byte, wenn UTF8 oder UCS2/Unicode(LittleEndian oder BigEndian unterscheide ich hier noch nicht). E.g. Field.(Data)Size vs. Field.DisplayWidth (Btw. wird verworfen, sobald TFields oder TParam zum Formular hinzugefügt werden, da ich nichts in eueren Einstellungen zu suchen habe).

Also VARCHAR(1700) reicht. Zeos determiniert seit 7.0 jeden bekannten CharacterSet und deren Bytes/Char.

Edit:

Habe bei 7.2 (SVN repo) den Fix inklusive rückwärts-Kompatibilität bereits gestern hochgeladen. Ist eigentlich recht simpel, WENN du NICHT mit default values arbeitest. Ist dem der Fall wird es komplizierter, da Integer, Floats, TimeStamps nun von CLOB's geladen und konvertiert werden müssen (e.g Meta-Daten)und 7.0 - 7.1 nicht darauf vorbereitet sind. 7.2 ist synchron mit \trunk und \testing-7.1, jedoch experimentel, da ich nicht mit nur 15%+ Speed über UniDac/ODBC zufrieden bin. Da geht noch was... Wird aber noch a bisl länger dauern, denk ich.