SQLITE - Rückgabewert von SELECT

[RuhrPotto]

Hallo zusammen,

ich hab wohl grad ein echtes Brett vorm Kopf. Die Tabelle in einer DB wurde wie folgt angelegt:

Code: Alles auswählen

CREATE TABLE IF NOT EXISTS tblKategorie (KATHID INTEGER, KATUID INTEGER, KATART INTEGER, KATBEZ VARCHAR(10), KATINFO VARCHAR(10), KATEST BOOLEAN)

Die Tabelle ist mit Testdaten gefüllt und wird

Code: Alles auswählen

SELECT * FROM tblKategorie

gelesen.
Die Rückgabemenge entspricht auch dem Ergebnis. Aber
Textfelder werden nur mit einer Länge von 10 Zeichen zurückgeliefert. Sind aber in der DB in richtiger Länge gespeichert.
Es macht auch keinen Unterschied, wie die Felder übertragen werden:

Code: Alles auswählen

sKat.KBez   := SqlQuery1.FieldByName('KATBEZ').AsString;
sKat.KInfo  := SqlQuery1.Fields[4].AsString; 

in beiden Fällen werden Texte auf 10 Zeichen gekürzt.

Hat hierfür jemand eine Erklärung und Lösung?

Danke schonmal

[mse]

"VARCHAR(10)" macht die Begrenzung. Da Sqlite3 intern keine Begrenzung anwendet, siehst du mit verschiedenen tools auch längere Texte.

[RuhrPotto]

"VARCHAR(10)" macht die Begrenzung. Da Sqlite3 intern keine Begrenzung anwendet, siehst du mit verschiedenen tools auch längere Texte.

Hatte ich mir bis dahin fast gedacht. Aber wie komme ich dann an den gesamten Text des Feldes?

[mse]

In MSEgui kann man eine Query z.B. so schreiben:

Code: Alles auswählen

 
select ID,cast(STR1 as VARCHAR) as STR1 from table1
 

um die Begrenzung zu entfernen. Ich weiss nicht, ob das auch in Lazarus funktioniert.

[hde]

warum creierst du denn VARCHAR(10) wenn du längere Texte willst?
Und womit greifst du zu? Zeos oder Lazarus?

[RuhrPotto]

Der Zugriff erfolgt über Lazarus.

Die Verwendung von VARCHAR(10) erfolgt aus Speicherplatzgründen. Aus anderes DB kenne ich es so, dass hierdurch nur der minimale angebene Platz für die Variable reserviert wird und dieser bei längeren Strings auf die tatsächliche bzw. maximal Länge extended wird. Das DB2 liefert zum Beispiel bei SELECT trotzdem die echte Länge des Strings zurück.
SQLITE scheint anderes zu arbeiten obwohl es die tatsachliche Länge und den Inhalt des Strings korrekt speichert.

Ich habe testweise den CREATE wie folgt

Code: Alles auswählen

KATBEZ VARCHAR, KATINFO VARCHAR

geändert.
Nunmehr liefert der SELECT die Strings in korrekter Länge zurück.

Ich habe die Felder in der Tabelle auch nicht als TEXT definiert, da diese Felder meines Wissens nicht indizierbar sind und später ein Sek-Index angelegt werden soll

[hde]

Die Verwendung von VARCHAR(10) erfolgt aus Speicherplatzgründen.

Sind deine rechner sooooo klein?
du kannst doch SQLite nicht mit DB2 vergleichen, das sind verschiedene Welten

[af0815]

in beiden Fällen werden Texte auf 10 Zeichen gekürzt.

Hat hierfür jemand eine Erklärung und Lösung?

Aus meiner Sicht, hat das System recht !

Wenn ich ein Datenbankdesign mache, dann muss ich mir vorher überlegen wie das Design der Tabellen wird (auch über die Lebensdauer des Systems gesehen). Sich da auf ein paar zufällige Spezialitäten von System zu verlassen ist grob fahrlässig.

Lösung, das Design richtigstellen. Eventuell eine Kurzbeschreibung mit beschränkter Länge und eine Langform, die eventuell auch als Text gespeichert werden kann, diese kann je nach System mit einem Volltextindex auch durchsucht werden. Siehe perform full-text searches on a set of documents wenn es sqlite sein soll.

[RuhrPotto]

1. Ich wollte ein DBMS vom Typ DB2 nicht mit SQLite vergleichen
2. Meine Rechner/HD's sind nicht klein

Aber ich mache mir Gedanken um das Design und Speicherplatz. Auch schon berufsbedingt aufgrund der Programmentwicklung auf Großrechnern.
Und - wenn ich zB. die Zahlenwerte [1..5] speichern will, dann nehme ich den Typ BYTE und nicht INTEGER oder CARDINAL.

Im Rahmen einer Portierung sollen typisierte Dateien in eine DB überführt werden. Auch hier definierte man doch nicht jedes Textfeld als STRING[255].

Es geht/ging mir nur darum, warum die Inhalte zwar korrekt eingegeben/übernommen werden aber im Rahmen des SELECT nicht vollständig zurückgeliefert werden.
Mir ist dabei auch klar, dass ich mich mit SQLITE noch nicht besonders gut auskenne und ich nicht alle Features von DB2 übertragen und verwenden kann.

[af0815]

Vielleicht ist die Full Text Search doch was für dich. Gerade wenn du typisierte Dateien überführst und den Platz optimieren willst. Die Frage ist hier, was der Inhalt der Dateien ist und ob man es mit FTS optimieren kann.