Varchar Felder und tatsächliche Länge in DB

[itec01]

Hallo Zusammen,
früher musste man die tatsächliche Länge eine Stringes eines varchar Feldes ermitteln und dann schreiben. Ist dies immer noch so notwendig, oder erkennt das System es mittlerweile automatisch? Ich möchte eigentlich nur einen eval varcharField = text machen.
Vielleicht gibt es mittlerweise auch BIF oder ähnliches?

Danke.

Gruß
Klaus

[Fuerchau]

In RPG wurden VARLEN-Felder ja nicht unterstützt, deshalb war dort die Länge in den ersten 2 Bytes anzugeben.

ILERPG unterstützt VARYING nun automatisch und führt die Länge nun intern.

Bei "MyVarLen = NewValue" wird die Länge aus dem NewValue ermittelt.
Ist NewValue ein Varying-Feld enthält es ja die Länge selber.
Ist NewValue ein Fixed-Feld wird die Länge mittels %size(Field) ermittelt.
Möchte man Leerzeichen abschneiden, dann hilft %trim(...) um aus einem Fixed-Feld ein Varying-Feld zu machen.

[andreaspr@aon.at]

Und bedenke auch dass ein MOVE die Zielvariable nicht auf die erforderliche Länge inizialisiert.
Mit EVAL oder auch im FREE wird das automatisch gemacht.
Am besten keine MOVEs für VARCHAR Variablen verwenden.

lg Andreas

[itec01]

Ok danke.
Dies bedeutet:

eval varcharField=%trim(text)

Dann müsste automatisch die Länge mit
drin stehen. Benötige ich dann noch bei der Umandlung die cvtoption(*VARCHAR)?

Danke.

[Fuerchau]

Die musst du auf jeden Fall weglassen!

*VARCHAR
Gibt an, daß Datenarten für Zeichenfelder variabler
Länge als Zeichenfelder fester Länge deklariert werden
sollen.

Die Option gilt nur für Felder aus DDS-Copies.

[itec01]

da sieht man mal wieder, dass die AS/400 nicht für solche Dinge gemacht wurde.
Man muss sehr aufpassen, dass man die Varchar Felder korrekt füllt.
Eine Zuweisung mit *blanks geht schief, weil hier der volle Wert genommen wird. Hier muss man geziehlt einen clear auf das varchar Feld machen.
Hat man in einem Programm sowohl das Füllen als auch das Auslesen eines Varchar Feldes geht es nicht mit dem %trim, weil man CVTOPT(*VARCHAR) benötigt. Hier muss man dann die ersten zwei Stellen manuell füllen.

Ich bin nun am Überlegen komplett auf die varchar Logik zu verzichten, weil ich auch denke, dass varchar Felder langsamer bei den Dateioperationen sind.
Was denkt ihr und wie habr Ihr dies organisiert?

Gruß

[B.Hauser]

VarChar-Felder werden zumindest mit EVAL sauber befüllt. Wenn Du allerdings in RPGIV immernoch mit MOVEs hantierst, ...

Wenn Du ein VarChar Feld mit *Blanks füllst ist klar, dass es komplett gefüllt wird. Um ein Feld zu initialisieren bzw. zu clearen ist der Befehl CLEAR da. Wenn Du willst kannst Du natürlich auch die Anzahl der belegten Zeichen mit %LEN setzten.

Beim Füllen aus Character Feldern mit fixer Länge wird nun mal die komplette Länge übertragen. Wenn Du die folgenden Blanks nicht benötigst musst Du diese eben mit einem %TRIM oder %TRIMR oder %SUBST entfernen.

Ich weiß nicht warum Du findest, dass das nicht logisch ist.

Birgitta

[Fuerchau]

weil man CVTOPT(*VARCHAR) benötigt ?

Achtung:
Wenn man diese Option verwendet, wird aus Varchar ein Feld fester Länge!
So wie ich es oben schon mal gesagt habe.
Klar muss man in diesem Fall die Längeninformation wieder selber verwalten.

Also diese Option nicht verwenden, dann klappts auch mit Varchar !!!

[itec01]

Hallo,
mal eine generelle Frage?
Ab welcher Feldlänge nutzt Ihr varchar Felder? Lt. Handbuch bedeuten varchar Felder meistens einen zweiten Plattenzugriff.
Ich habe ab einer Länge von 100 Byte damit begonnen varchar Felder mit varlen(1) zu nutzen. Nun habe ich im Handbuch gelsesen, dass man als varlen die Länge nehmen soll, die meistens gefüllt. Das lässt sich nicht immer so einfach sagen. Auf jeden Fall soll es Probleme mit der Performance geben. Ich habe nun größte Bedenken bei Tabellen mit ca. 10 Mio. Sätzen und einigen Varchar Felder.


Danke.

Klaus

[B.Hauser]

1. bis zu einer Länge von 32 Zeichen werden die Daten nicht in die Overflow-Area geschrieben, sondern direkt im Datensatz verwaltet. Ich gebe trotzdem immer explizit die reservierte Länge (ALLOCATE(x) in SQL Tabellen oder VARLEN(X) in DDS Dateien) an.
2. Wenn Du VARLEN ohne Zusatz oder VARCHAR ohne ALLOCATE definierst werden alle Texte für Spalten mit mehr als 32 Zeichen in der Overflow-Area gespeichert, wodurch ein Extra-Zugriff erforderlich ist. (Kommt noch aus der Zeit als Speicher knapp und teuer war.)
3.Die Empfehlung lautet, dass die beste Performance dadurch erreicht werden kann, wenn ca. 80+ % aller Daten im Datensatz gespeichert werden. Der zusätzliche Zugriff auf die Overflow-Area erfolgt nur für die Ausreißer, d.h. die Texte die länger als die reservierte Länge sind.
3. Der (zusätzliche) Zugriff in die Overlow-Area wird nur dann kritisch, wenn gleichzeitig Large Object-Spalten verwendet werden. Soweit ich das bei Dir beurteilen kannst arbeitest Du mit DDS beschriebenen Dateien, bei denen eh' keine LOBs definiert werden können.

Die Verwendung von Feldern mit variabler Länge ist z.B. auch beim Selektieren besser, da die belegte Länge im Feld hinterlegt ist und dann auch nur diese Anzahl an Zeichen verglichen wird.
Weiterhin ist ein TRIM nicht erforderlich, der bei großen alphanumerischen Feldern mit fixer Länge ebenfalls zeitintensiv ist, da beginnend von der letzen Stelle aus rückwärts geprüft werden muss.

M.E. sind Felder mit variabler Länge sooft wie möglich verwendet werden (Ausnahme vielleicht kurze Felder bis 10 Zeichen).

Birgitta

[BenderD]

... die Verwendung von varchar ist im Bereich von Oracle und DB2 auf Mainframe Standard und das spricht eindeutig für varchar. Auf der AS/400 wäre ich da sehr vorsichtig und würde das vorher mal benchmarken, wie sich das auswirkt. Meine letzten Benchmarks in dieser Richtung (muss so V5R2 darum gewesen sein) waren katastrophal, das war um mehr als 20 % langsamer, bei Flächen deckender Verwendung von Varchar.

D*B

[Fuerchau]

Ein Vergleich von Varlenfelder oder Fixed-Feldern im SQL ist unerheblich, da bei unterschiedlicher Länge der Rest mit Blanks angenommen wird.
Ein Trim wird hier nicht durchgeführt, da der Vergleich auf MI-Ebene erfolgt (CMPBLA = ohne Blanks, CMPBLAP = mit Blanks) und bewegt sich im Nanosekundenbereich.

Entscheidend ist natürlich der 2. benötigte Zugriff, deshalb die allocierte Länge.
Da ein Datensatz ohne LOB's aber 32KB nicht überschreiten kann, sind Varlenfelder mit Überlaufbereich eher kontraproduktiv.

In DDS kann man daher besser die Allocate-Länge auch auf die max. Länge setzen.