Leerzeichen in Strings / M$ SQL Server 2000

[Bart Simpson]

Ich bin dabei eine kleine Applikation in Delphi6 zu schreiben, die Daten von einem M$ SQL Server 2000 holen bzw. verändern soll. Mein Problem ist, dass wenn ich via TADOConnection -]  TDataSource -] TDBEdit ein Feld anzeigen lasse, das Strings beinhaltet (am Server: char(100)), diese zwar den eigentlichen Inhalt anzeigen, aber zusätzlich noch soviele Leerzeichen wie eben in das Feld passen. D.h. wenn mein Inhalt 5 Zeichen lang ist, kommen zusätzlich noch 95 Leerzeichen (vielleicht sind's auch ein paar mehr oder weniger... ich hab's nicht wirklich nachgezählt ;-)

Ist das ein allgemeines Problem der ADO Komponenten (glaub ich nicht, denn wenn ich die Daten via Access XP abfrage erhalte ich die gleiche Antwort vom Server), oder ist das nur der SQL Server 2000 oder was sonst?
Kennt irgendjemand eine Möglichkeit dieses "Fehlverhalten" zu umgehen/auszuschalten/wasauchimmer...

Ich hab mit schon überlegt 'ne Komponente von TDBEdit abzuleiten, die das ausgleicht, aber woher soll die denn wissen, ob die Leerzeichen nicht tatsächlich zum String gehören oder nur hinzuphantasiert wurden?
Die andere Alternative wäre an den entsprechenden Stellen eine Trim-Funktion herumzubasteln...aber das ist auch nicht das gelbe vom Ei!

Dankbar für alle Hinweise/Tips

Bart Simpson

[Adrian Hämmerli]

also ich mag mich da wage an was erinnern, dieses Problem habe ich auch mal gehabt.

Habe dann einfach den Datentyp gewechselt können zb. in VarChar.

Werde aber nochmals meine Bücher wälzen.

[Loïs Bégué]

Hi,
Es ist ja kein Fehlverhalten der Datenbank oder der ADO-Objekte.
Felder die mit dem Typ CHAR(AnzahlZeichen) definiert worden sind haben eine feste Länge (eben entsprechend der angegebenen Zeichenzahl). Das spart 2 byte pro Datensatz und Feld, die sonst für die Bestimmung der Länge benötigt werden. Wie Adrian meinte, die Alternative ist VARCHAR(AnzahlZeichen).
Ein weitere Nachteil von CHAR-Felder ist auf jeden Fall in einer Client/Server Umgebung, daß die 100 Bytes (5 Zeichen + 95 Leerzeichen)deines Feldes auf jedem Fall mit auf die Reise gehen, wenn ein Datensatz aufgerufen und durch die Netzwerkverbindung gejagt wird.

Nun weiß ich nicht genau wie es ist mit MS Server, aber mit Interbase war das Problem der Anzeige somit gelößt. In der IB5 Version war das aber keinesfalls so, daß bei einem  VARCHAR(100)-Feld mit nur 5 eingegebenen Zeichen nur diese 5 übertragen wurden. Soweit ich mich erinnere wurden die Leerzeichen erst bei "Ankunft" wegoptimiert...

Ein Workaround könnte bei dir sein, daß du einen "computed"-Feld für die Anzeige benutzt. Es gibt dann ein Ereignis "OnCalculateDatafield" (oder so ähnlich) den du benutzen kannst, um den angekommenen Feldinhalt mit einer Trim-Funz für die Bildschirmausgabe zu bearbeiten bzw. vorzubereiten...

Gruß,

(Es lebe Interbase :o)

[Adrian Hämmerli]

Diese Aussage das der "Char " in einer C/S umgebung die schlechtere wahl ist kann man ja so nicht stehen lassen.

Es kommt doch immer darauf an für was ich dieses Feld verwenden.

zb. Wenn ich weiss wieviele Zeichen ich speichern möchte ist Char der Bessere Typ.

Und wenn ich mich richtige erinnere ist der Zugriff auf ein Feld mit den Type Char schneller als zb. VarChar.

[/quote]

[Loïs Bégué]

@Adrian Hämmerli:

Diese Aussage das der \"Char \" in einer C/S umgebung die schlechtere wahl ist kann man ja so nicht stehen lassen.  

Also, ich habe meinen Beitrag nochmals durchgelesen. Du auch ?-)

Von "schlechtere Wahl" war da auf keinem Fall die Rede. Nix da. Keine Spur. Von einem Nachteil, wenn Du 95 "leeren" von 100 Zeichen regelmäßig übertragen muß, das schon.

Wenn ich bei den Kunden meiner Firma täglich 185000 Datensätze pro Person a 10 Arbeitsplätze durch ein mit anderen Strukturen/Programmen/Servern geteilten Netzwerk schieße, und stelle fest, 95 bytes von 100 sind durchschnittlich für besagtes Feld umsonst durchgereicht worden, dann tue ich gut etwas daran zu ändern  L:)

Übrigens:
Perform-mäßig sollte, wenn es wegen Sortierungsbedarf indiziert wird (sagen wir mal auf- und absteigend) :
Beispiel:
Stelle Dir mal 25000 Kundenanschriften mit einem Feld "PLZ".
Jo.
Die Kunden sind in allen Ländern der Welt.
Also nix mit einer festen "logischen" Länge von 5 Zeichen, die als Integer zu speichern wären.
Alphanumerisch muß das Feld sein. Und die Länge ist ungewissss.
Nun.
Im durchschnitt könnten 20 Kunden pro PLZ zu finden sein.
Hast Du das Feld als CHAR(15) deklariert, dann gibt es wahrscheinlich Ärger bei der Sortierung: der Vergleich dürfte bis zur letzten Stellen der Zeichenkette reichen für jeder dieser 20er Gruppe...
Es ist nicht eine Tasse-Kaffee die Du in der Wartezeit trinken darfst sondern den Inhalt eines "Eighteen-Wheeler-Tank". Und ich sage Dir: es ist nicht schlimmeres als USA-Kaffee :o)

Mierda !!! Ich hatte vergessen: wenn "PLZ", dann auch "PLZ des Postfaches". Doppel-Belastung also, da das Feld seltener gefüllt wird...Mamamiacarambasalsaconchipolata...  <):-)  Olé  !-]

Also für die CHAR(...) gilt klar: Selten wenn überhaupt, aber immer wieder wenn man's braucht.
Gute beispiele bzw. Kandidate für CHAR(...) sind:
- Barcodes in einem für die Tabelle festgelegten Format (z.B. nur EAN128)
- Steuernummern, Warennummer oder Zoll-Ids usw. also alles was "amtlich"-festgelegt ist.
- ISO-Codes in manchen Bereiche (z.B. Länder ISO-Codes)
- Sehr lange lange lange (vielfältige) Angaben wenn es viele Datensätze gibt.
- Sehr sehr sehr kurze Angaben bei wenig (und eher eindeutiger) Datensätze mit Sortierung (Z.B. Dateiformat-Extensions in einer Picture-Typ-Tabelle)
- Sehr sehr sehr kurze Angaben bei viele Datensätze aber ohne Sortierung (da die Häufigkeit der Übereinstimmung mehreren Einträge keine grosse Rolle mehr spielt).

Voila.

P.S:

Lao Tseu sagte:
"Rache ist unnötig und absurd.
Setze Dich einfach am Uffer und Bald wirst Du den Kadaver Deines Gegners vorbeischwimmen sehen..." :o)

Gruß,

[Bart Simpson]

Also das Umstellen auf Varchar bringts... dämlich aber war.
Na schön... ich wollt zwar nicht unbedingt Varchar verwenden (über das für und wieder wurde ja schon ausführlich debatiert), aber wenn's denn sein muss...
Aber ich halte es trotzdem für ein idiotisches Verhalten... meinetwegen soll er ruhig 95 Zeichen lang Mist übertragen-von mir aus! Aber: Das DARF keinen Einfluss haben auf mein Ergebnis! Ein klares StringEnde á la #0 und dann nur noch Müll -OK... aber so nicht!

Anyway... Danke für den Tip!

Bart Simpson

[Bart Simpson]

Nur zur Info, falls jemand neugierig ist ;-)

Ich hab den wahren Grund für das Verhalten herausgefunden: Er ist historischer Natur... Char und Varchar sind bei SQL Servern im Prinzip das gleiche, nämlich Strings mit fester maximaler Länge. Der kleine aber feine Unterschied besteht nur darin, dass der SQL Server bei Char _immer_ mit Leerzeichen auffüllt! Das sollte in den Urzeiten der Computertechnik mal das ausgeben am Bildschirm erleichtern (Monospaced Characters & Bildschirmmasken) und ist eben als Relikt im SQL Standart erhalten geblieben.
Tja, Wissen is Macht!

Bart Simpson