-
DDL Tabel mit default CCSID
Hallo Zusammen,
wir erstellen mittlerweile neue Tabellen mit DDL und nicht mehr mit DDS.
Nun ist hier die Frage kann ich hier auf Tabelleneben die CCSID angeben?
So wie hier im DDS:
Code:
A CCSID(1208)
A R TESTPF1
A TSTEXT 20A
Im Internet habe ich sowas gefunden:
Code:
CREATE TABLE UNITAB
(C1 CHAR(4)FOR SBCS DATA,
C2 CHAR(4),
C3 GRAPHIC(4),
C4 VARCHAR(4) FOR SBCS DATA,
C5 VARCHAR(4),
C6 VARGRAPHIC(4))
CCSID Unicode
Aber da bekomme ich immer die Fehlermeldung CCSID ungültig
Alternativ wäre ich auch glück wenn ich System weit für DDL Tabellen eine Default CCSID angeben kann
Vielen Dank schon Mal
-
Das Notwendige steht über dem technisch machbaren.
(klingt komisch, funktioniert aber!)
-
Moin Robi,
ja das kenne ich aber das ist ja um DDS zu DDL zu konvertieren.
Ich würde jetzt aber gerne bei neuen DDL nicht an jeder Spalte die CCSID 1208 angeben müssen sondern diese einmal vor definieren.
Entweder:
auf Tabellenebene
Auf Systemebene
oder beim Befehl - RUNSQLSTM (womit ich die Tabellen erstelle)
-
Nein, das ist nicht vorgeshen. Bei SQL muss jedes Feld explizit die CCSID angegeben werden.
Allerdings weiß ich nicht warum du unbedingt 1208 (UTF8) verwendest.
Diese CCSID wird beim Lesen/Schreiben native nicht mit Codewandlung unterstützt.
Du hast dann im ILERPG genauso wieder den 1208-Code und benötigst Konvertierungen für die korrekte Verarbeitung.
Sicher ist da 1200 (UCS2 bzw. UTF16), was sich in dem Feldtyp "C" (UCS2) im Programm wiederspiegelt.
Mittels SQLTyp NCHAR/NVARCHAR wird CCSID 1200 bereits angegeben und du brauchst keine CCSID anzugeben.
Für Datenaustasch (FTP, CSV, ..) kann man dann wieder 1208 verwenden.
-
Zitat von Fuerchau
Nein, das ist nicht vorgeshen. Bei SQL muss jedes Feld explizit die CCSID angegeben werden.
Allerdings weiß ich nicht warum du unbedingt 1208 (UTF8) verwendest.
Diese CCSID wird beim Lesen/Schreiben native nicht mit Codewandlung unterstützt.
Du hast dann im ILERPG genauso wieder den 1208-Code und benötigst Konvertierungen für die korrekte Verarbeitung.
Sicher ist da 1200 (UCS2 bzw. UTF16), was sich in dem Feldtyp "C" (UCS2) im Programm wiederspiegelt.
Mittels SQLTyp NCHAR/NVARCHAR wird CCSID 1200 bereits angegeben und du brauchst keine CCSID anzugeben.
Für Datenaustasch (FTP, CSV, ..) kann man dann wieder 1208 verwenden.
... man kann schon auf Dateiebene die CCSID vergeben (wird aus dem Job beim create table übernommen). Dass das dann ausgerechnet für Unicode (1200, 1208, 13488) nicht geht, weil das weder für den Job, noch für CHGPF geht, ist für mich ein Anachronismus, insbesondere weil es da auch keine andere Möglichkeit gibt. Als Default sollte man bei einer modernen Datenbank ohnehin eher Unicode erwarten dürfen.
D*B
-
Das war schon immer so bei DDL.
Die CCSID auf Dateiebene gabs nur für den CRTPF und auch nur dann, wenn auf Feldebene keine CCSID angegeben wurde. Wird bei nur einem Char-Feld explizit eine CCSID angegeben wird bei allen anderen Char-Feldern ohne CCSID automatisch *HEX, also Binary angenommen.
Auf Dateiebene wird hier bei fehlender Angabe dann die Default-CCSID (Achtung: nicht die Job-CCSID) verwendet.
Bei SQL wird für [VAR]CHAR automatisch die Default-CCSID und für N[VAR]CHAR eben 1200 (UTF16) verwendet. Die Krücke mit [VAR]GRAPHIC CCSID 13488 entfällt ja seit dem N-Type.
Wo ist da das Problem?
-
Zitat von Fuerchau
Das war schon immer so ...
... das hamwer noch nie so gemacht, da könnt ja jeder kommen!
-
Danke für die vielen Antworten.
An UTF-8(1208) hatte ich gedacht da dieses ja bei überwiegend Lateinischen Buchstaben weniger Speicher verbrauchen soll.
Ich möchte jetzt die neu definerten Tabellen nicht gleich alle mit der "falsche" CCSID erstellen
Also kann ich nicht einfach im RPGLE das CCSID 1208 Feld(aus der Tabelle) in eine Job CCSID Feld scheibe, da die dann nicht richtig umgesetzt werden?
Aber wenn ich nVarChar verwende dann kann ich das einfach mit %Char() und %UCS2() machen?
-
Korrekt. Wobei inzwischen %char() und %ucs2() weitgehend überflüssig sind, da die Runtime inzwischen so intelligent ist, dass sie das automatisiert.
Was UTF8 angeht, so musst du hier theoretisch die 4-fache mögliche Zeichenkapazität berücksichtigen, wobei 2-fach ausreicht, ein Ü belegt 2 Bytes, in ein 30-stelliges Feld bekommst du dann nur 15 Ü's. Gespart hast du da nichts. Deshalb NCHAR, das ist generell 2 Bytes je Char.
Außerdem:
Mach mal mit SQL ein Select auf ein UTF8-Feld, DSPPFM u.ä. Dies betrifft also nicht nur RPG sondern alle Zugriffe incl. ODBC/JDBC. Alleine um einen Substring bzw. %subst() korrekt durchzuführen musst du das Feld erst mal in UCS2 wandeln, da Umlaute ja die Zeichenposition bereits verschieben.
-
ok ich hab das bei mir jetzt mal getestet und die Felder in einer Tabelle von VarChar zu nVarChar geändert.
Bin positiv überrascht das dieses ohne Datenverlust funktionierte
habe beim RPG jetzt nur wie du beschrieben hast ein Problem beim %Trim und %SubStr
Das ist jetzt ein bisschen gewöhnungsbedürftig
%trimr(FELD:%ucs2('/'))
Aber vielleicht lässt die IBM hier dann auch mal eine schlaue Konvertierung von Konstanten zu
-
dcl-s SchraegStrich ucs2(1) inz(%ucs2('/'));
%trimr(FELD:SchraegStrich)
Das Problem ist doch, dass in der Quelle das Zeichen "/" in EBCDIC angegeben ist, du aber UCS2 benötigst. Dies geht halt dann nur mit Cast oder eigenen Konstanten.
Da aber Unicode keine weitere Codewandlung erfährt, kannst du Konstanten auch in der u-Notation schreiben:
%trimr(FELD:u'002F') // x'2F' = "/"
Übrigens: Für die U-Notation hilft dir die Windows "Zeichentabelle".
Wählst du ein Zeichen aus, wird dir in der Fußzeile die u-Notation angezeigt.
Wenn du das mit dem %ucs2 lässtig findest, kannst du ja auch SQL nehmen;-):
exec sql set : Ziel = trim(trailing '/' from : Quelle);
-
das mit der U-Notation kenn ich werde auch mal überlegen für die Konstanten dann einen Include Quelle anzulegen.
um den Code dafür raus zu finden nutzte ich sehr gerne diese Seite
https://unicode-table.com/de/
Wie definiere ich denn dann am Besten CLOB und BLOB?
Ohne Angabe von CCSID oder dann mit 1200?
Similar Threads
-
By malzusrex in forum NEWSboard Programmierung
Antworten: 18
Letzter Beitrag: 22-01-20, 09:46
-
By loisl in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 23-05-16, 15:23
-
By DEVJO in forum NEWSboard Programmierung
Antworten: 12
Letzter Beitrag: 29-09-15, 14:07
-
By Toschie in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 15-01-15, 11:26
-
By karin-vogelmann in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 21-03-03, 12:39
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks