[NEWSboard IBMi Forum]
Seite 1 von 2 1 2 Letzte
  1. #1
    Registriert seit
    Jun 2013
    Beiträge
    69

    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

  2. #2
    Registriert seit
    Jun 2001
    Beiträge
    1.973
    ganz auf die schnelle ...
    Kennst du das https://www.itjungle.com/2016/05/17/fhg051716-story02/
    Das Notwendige steht über dem technisch machbaren.
    (klingt komisch, funktioniert aber!)

  3. #3
    Registriert seit
    Jun 2013
    Beiträge
    69
    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)

  4. #4
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  5. #5
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    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
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  6. #6
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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?
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  7. #7
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    Zitat Zitat von Fuerchau Beitrag anzeigen
    Das war schon immer so ...
    ... das hamwer noch nie so gemacht, da könnt ja jeder kommen!
    AS400 Freeware
    http://www.bender-dv.de
    Mit embedded SQL in RPG auf Datenbanken von ADABAS bis XBASE zugreifen
    http://sourceforge.net/projects/appserver4rpg/

  8. #8
    Registriert seit
    Jun 2013
    Beiträge
    69
    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?

  9. #9
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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.
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  10. #10
    Registriert seit
    Jun 2013
    Beiträge
    69
    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

  11. #11
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    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);
    Dienstleistungen? Die gibt es hier: http://www.fuerchau.de
    Das Excel-AddIn: https://www.ftsolutions.de/index.php/downloads
    BI? Da war doch noch was: http://www.ftsolutions.de

  12. #12
    Registriert seit
    Jun 2013
    Beiträge
    69
    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

  1. SQL UDF mit Tabel
    By malzusrex in forum NEWSboard Programmierung
    Antworten: 18
    Letzter Beitrag: 22-01-20, 10:46
  2. SQL - Create Tabel - Objektberechtigung *PUBLIC auf *CHANGE
    By loisl in forum NEWSboard Programmierung
    Antworten: 6
    Letzter Beitrag: 23-05-16, 16:23
  3. create tabel ohne level check
    By DEVJO in forum NEWSboard Programmierung
    Antworten: 12
    Letzter Beitrag: 29-09-15, 15:07
  4. System Default-Parameter
    By Toschie in forum IBM i Hauptforum
    Antworten: 3
    Letzter Beitrag: 15-01-15, 12:26
  5. DEFAULT-instanz in HTTP-server
    By karin-vogelmann in forum IBM i Hauptforum
    Antworten: 2
    Letzter Beitrag: 21-03-03, 13:39

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • You may not post attachments
  • You may not edit your posts
  •