Zitat von
Robert_G:
Genau darauf würde ich mich nicht verlassen. Mir ist es oft genug untergekommen, dass für einen VarChar2 2 B/Chr verwendet wurden.
Bei MS-
SQL sollte das aber nicht der Fall sein (evtl. bei anderen
DB's). Auszug aus der MS-
SQL-Hilfe
Zitat:
varchar[(n)]
Nicht-
Unicode-Zeichendaten variabler Länge mit n Byte. n muss ein Wert zwischen 1 und 8.000 sein. Die Speichergröße entspricht der tatsächlichen Länge der eingegebenen Daten in Byte, nicht n Byte. Die eingegebenen Daten können 0 Zeichen lang sein. Die
SQL-92-Synonyme für varchar sind char varying oder character varying.
Zitat von
Robert_G:
Wenn es im
SQL Svr wirklich nur 1 B/Chr ist, kannst du dich bei 8KB doch ziemlich auslassen (solange es wirklich nur "kleinere" Felder sind).
Muß jedoch dafür sorgen, das wenn der User die Konfiguration so wählt, das er evtl. über diese Grenze, das 'ne Warnmeldung erscheint.
Zitat von
Robert_G:
OT: Diese Einschränkung ( die 8 KB) gehört wohl neben dem SELECT-Locking zu den nervigsten "Features" von M$ Spross...
Ich kenn noch eine: Tabelle mit Primärschlüssel(varchar), varcharfeldern und ntext-Feldern.
Und versuch mal in einer Update-Anweisung alle Felder gleichzeitig zu aktualisieren - Wird nicht gehen!
OT: Wenn man mehr mit den diversen
DBMS zu tun hat, so wundert man sich nicht, das immer wieder neue
DBMS entwickelt werden
