SQlite und varchar(n)

[mb0156ba]

Hallo zusammen,

habe gerade meine ersten Gehversuche mit SQlite gemacht und bin dabei gleich mal auf eine...nunja...etwas seltsames gestoßen. zumindest finde ich es etwas unerklärlich und leider habe ich im Web bisher keinerlei helfende und weiterführende Informationen gefunden.

Es geht jedenfalls um Folgendes:

Eine Tabelle wird wie erzeugt

CREATE TABLE test
(id integer,
name varchar(4)
);

und jetzt wird die Tabelle befuellt:

INSERT INTO test (id, name)
VALUES (1, "Dies ist ein Testeintrag!");

So, spätestens als das ohne Fehlermeldung funktionierte wurde ich stutzig. Wie kann der ohne Fehlermeldung einfach so mal eben 25 Zeichen in nen varchar(4) schreiben? Aber okay, vllt. meckert er einfach nur ned und machts trotzdem richtig, also:

SELECT * from test;

und man erhält Folgendes:

1|Dies ist ein Testeintrag!

Ohne dass irgendwas abgeschnitten wäre, ohne Meldung, ohne alles.
Unter uns: Ich habe das ganze auch mal mit nem varchar(255) ausprobiert und da ließen sich ebenso problemlos Stings >290 Zeichen eintragen und fehlerfrei auslesen.

So und jetzt die Frage:
Verstehe ich den varchar(n) einfach nur falsch? Meines Erachtens nach dürfte man in nen varchar(4) nur 4 Zeichen schreiben können und die Datenbank müsste das absichern, wenigstens irgendeinen Fehler ausgeben. Oder doch zumindest abschneiden. oder kann das SQlite einfach nur nicht? *verwirrt*

Und da sind wir auch schon bei Frage zwei:
Wie groß kann n bei varchar(n) maximal werden? Bei Access und MySQL is das ja auch 255 Zeichen beschränkt, MS SQL und andere sind da wesentlich freizügiger hab ich mir sagen lassen...aber über SQlite habe ich diesbezüglich leider noch gar nichts gefunden...

Also...ich hoffe ich habe mein Anliegen halbwegs verständlich vorgebracht. Würde mich über jeden Tipp, Hinweis und jede Anregung freuen. Danke schonmal!

Gruß
Alex

[Andreas Kosch]

Hallo,

Verstehe ich den varchar(n) einfach nur falsch?

nein, der Grund für diese Anomalie liegt darin, dass man im Fall von SQLite in eine ca. 250 kByte große DLL keine "richtige" SQL-Datenbank unterbringen kann ;-)

[mb0156ba]

Okay...dann muss ich eben bei der Anwendung bissl n Finger drauf haben...oder mir irgendwann vllt. ne andere "mächtigere" Lösung ausdenken.

Danke für die Info!

Gruß
Alex

[Bernd Schulz]

Hallo!

Warum warten?
Es gibt ausreichend kostenlose Anbieter und fast jeder "Große" bietet eine Lite Version an.
Wir nutzen bei kleinen Installationen die MSDE von Microsoft.
In InstallShield kann ein fertiges Setup für die MSDE eingebunden werden und gut is.

BYE BERND

[Bernhard Geyer]

> Es gibt ausreichend kostenlose Anbieter und fast jeder "Große" bietet eine Lite Version an.
Jeder dieser "Großen" hat den nachteil das er Installiert werden muß. Lösungen wie SQLLite laufen komplett ohne installation (sogar von CD):

[Andreas Kosch]

Hallo Bernhard,

Jeder dieser "Großen" hat den nachteil das er Installiert werden muß..

Diese pauschale Aussage ist nicht korrekt. Die kostenfrei verfügbare Microsoft SQL Server 2005 Compact Edition muss nicht installiert werden. Das XCOPY-Deployment von 7 sqlce-Assemblies (DLLs) reicht völlig aus. Alternativ dazu wird jedoch auch ein reguläres MSI-Setup angeboten, so dass der Entwickler den Weg auswählen kann:

a) MSI: Windows Update kümmert sich automatisch um Upgrades
b) XCOPY: Die installierten Assembly-DLLs werden nicht von Windows Update aktualisiert.

[Bernhard Geyer]

> Diese pauschale Aussage ist nicht korrekt. Die kostenfrei verfügbare Microsoft SQL Server 2005 Compact Edition muss nicht installiert werden.

Das mag stimmen wenn .NET 2.0 auf dem Rechner ist (Ist doch auch eine .NET 2.0 Anwendung?). Aber solange dies nicht bei 99,9% der Rechner welche für die eigene Zielkundschaft der Fall ist ist ein Installer nötig. Man will ja den Kunden nicht gleich mit einem Absturz begrüßen wenn die eigene .NET-Anwendung auf eine Zielsystem trifft auf dem kein .NET ist. In 2-3 Jahren mag das anders sein.

Aber gut zu wissen das sowas möglich.