[NEWSboard IBMi Forum]
Seite 2 von 4 Erste 1 2 3 ... Letzte
  1. #13
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Ich muss doch noch etwas fragen: Ein Kollege vertrat die Meinung, dass eine Umstellung auf DBCS wegen Fremdsprachen nicht immer notwendig ist. Die gängigen Sprachen (alle mit lateinischen Buchstaben, sowie die mit griechischen und kyrillischen Zeichen) müsste man mit den Single Byte Character Set abbilden können. (Klar: Japanisch geht dann nicht).

    Wenn das so ist und ein spanischer Anwender gibt ein Zeichen ein, das unser deutscher Zeichensatz nicht kennt: Dann müsste ein deutscher Anwender ja ein Ersatzzeichen sehen. Wenn der deutsche Anwender das dann wieder speichert, macht er dem spanischen Anwender dann seine Daten kaputt?

  2. #14
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... wenn man denn bei den Daten weiß, wo sie herkommen und wie sie codiert sind, kann man auch eine Unicode View über die Daten stellen; bzw. das Unicode Feld zusätzlich führen und per Trigger erzeugen und konsistent halten. Die Anwendung selber bleibt dabei unberührt. Zu Deiner Ausgangsfrage: selbst bei zurückschreiben der gelesenen Daten bleibt der Inhalt in Hex erhalten solange man keine Eingaben in diesen Feldern macht.

    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/

  3. #15
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Vielen Dank! Die Idee mit der View werde ich hier mal ansprechen.

  4. #16
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Nun ja, das mit den Sprachen verhält sich da etwas anders.
    Die CCSID's werden zusätzlich in Sprachgruppen geführt. Diese sind dann mit Latin-1 bis inzwischen latin-15 aufgeteilt.
    Alle CCSID's einer Latin-Gruppe lassen sich ohne Verlust hin und her konvertieren.
    CCSID's unterschiedliche Latin-Gruppen führen bei der Konvertierung zu Verlusten.
    Vor Einführung von Unicode konnte man z.B. zwischen 273 und 870 nicht konvertieren, der Open einer Tabelle schlug fehl.
    Ab einem bestimmten Zeitpunkt wurde die Konvertierung wohl auf 2-stufig umgestellt, d.h., 1. Stufe in UCS2, 2. Stufe in Ziel-CCSID.
    Solange man dann die Daten nur liest, ist es unkritisch.
    Schreibt man die Daten zurück, werden sie nicht mehr korrekt zurückkonvertiert, da bei der Hin-Konvertierung Ersatzzeichen oder "?" verwendet wird. Sporadisch gibt es aber bei einigen CCSID-Kombinationen trotzdem was auf die Finger.
    In ILERPG hat man halt das Problem, dass beim Lesen alle Felder die definiert sind (z.B. als DS), gefüllt und beim Update zurückgeschrieben werden.
    In SQL kann man gezielt sich auf die Felder beschränken.
    Übrigens ab irgendwann kann man beim Update in Free in Klammern die Feldliste angeben.
    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. #17
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Die Idee ohne Unicode auszukommen geht eingeschränkt natürlich auch, in dem man für jeden Sprachraum eine eigene Tabelle mit der gewünschten CCSID anlegt und die Daten dort pflegt.
    Allerdings ist dann erforderlich, dass Tabelle, Job und Terminal alle mit derselben CCSID fahren, damit es nicht zu Darstellungsverlusten kommt.
    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

  6. #18
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Nochmals danke. Ist ein sehr komplexes Thema. Mich würde interessieren, was andere IBM i Anwender machen. Es ist ja oft so, dass man weiß, was theoretisch die beste Lösung ist, dass man aber in der Praxis doch eine einfachere (bzw. bekannte) Lösung wählt. Habt ihr zum großen Teil wirklich eure Tabellen auf DBCS umgestellt?

  7. #19
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Nachtrag:
    Hier muss ich noch mal D*B recht geben.
    Ich kann durchaus mehrere SBCS-CCSID's in einer Tabelle unterbringen (sowas schule ich auch), wenn man bestimmte Dinge berücksichtigt:
    - zwischen DB und Job findet keine Umwandlung statt, wenn Job+DB-CCSID identisch ist oder der Job auf 65535 (*hex) steht
    - Zwischen Job und DSPF/PRTF findet (ohne besondere Maßnahmen) keine Codewandlung statt
    Also, Daten, die an einem 870-Terminal erfasst werden landen so binär auch in einer 273-DB.
    Zu beachten ist lediglich, dass die Daten auch nur an einem 870-Terminal oder in einem 870-Spool korrekt wiedergegeben werden können.
    Ich muss also ggf. zusätzliche Flags haben, um dies u.U. zu berücksichtigen (z.B. in einer View mit einem case-Verteiler für die Umwandlung in Unicode).
    Wie Dieter schon sagte, solange ich die Daten nicht verändere werden sie binär betrachtet.
    Beim Drucken muss ich dann berücksichtigen, dass ggf. beim Wechsel des Sprachflags eine andere PRTF (ggf. per OVRPRTF) mit anderer CHRID geöffnet werden muss.
    Zu beachten ist dabei lediglich, dass auch die Drucker unterschiedliche Hardwarefonts unterstützen müssen.
    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

  8. #20
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    @DSchroeder
    Die einfachste Form ist tatsächlich Unicode!
    Alles andere führt unweigerlich zu weiterführenden Maßnahmen, zumal man ja bedenken muss, dass ODBC-Clients per Default in Unicode arbeiten (außer alten C++-Anwendungen, die nicht explizit in Unicode entwickelt wurden).
    Leider ist dann so, dass solche angedachten "einfachen" Lösungen dann durchaus viele Jahre Bestand haben.
    Gerade hierzu hatte ich letztens ein Beispiel:
    Die deutschen Umlaute sind in vielen Sprachwelten vertreten, haben aber immer wieder andere Codepoints. So ergab sich dereinst die Situation, dass in einer polnischen Niederlassung durchaus grenznahe deutsche Lieferadressen erfasst wurden.
    Leider wurden dieselben Adressen auch von Deutschland benötigt, und eine Adresse gibt es halt nur einmal.
    Bei den Anzeigen und Drucken viel dann immer häufiger auf, dass die Umlaute wiedermal falsch waren.
    Erst nach Einsatz eines Triggers wurde dann festgestellt, dass in Polen und Deutschland die Adresse ständig korrigiert wurde.
    Beim Einsatz von Unicode (auch mit 5250-Terminals) wäre das halt nicht passiert.
    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

  9. #21
    Registriert seit
    Mar 2002
    Beiträge
    5.286
    ... das mit dem View Layer, haben wir mal in einem BI Umfeld so gemacht. Ausgangslage waren:
    - an die zehn Seperat Installationen der (fast) gleichen Software, für jede Auslandsgesellschaft eine.
    - die komplette operative Software war klassisch mit Singlebyte, jeweils passende Codierung pro Installation
    - die CCSIDs der Tabellen war teilweise falsch, funktioniert hat das nur nach dem MIMO Prinzip (sprich die Fehlcodierung der Eingabe war invers zur Fehlumsetzung bei der Ausgabe)
    - im Datawarehaus sollten nun diese (auf den ersten Blick) inkompatiblen Bestände zusammengeführt werden.
    - im Ladeprozess haben wir alles mit einem Mandantenkey (der letztlich auch die Codierung erkennen ließ) erweitert zusammengekippt

    Dann haben wir im View Layer die Textfelder nach Unicode gecasted (technisch braucht es da Zwischencasts nach 65535, damit einem die automatischen Umsetzungen nicht dazwischen fuhrwerken)

    Final war uns das dann für einige Tabellen zu langsam. Da haben wir dann zusätzliche Unicode Felder angehängt, die von Triggern gepflegt wurden.

    Im View Layer haben wir dann Tabellen für alte Welt (single Byte korrekte CCSID) dargestellt und für neue Welt Unicode.

    Da es sich um etliche Tabellen und Felder handelte, haben wir für alle erforderlichen SQL Skripte (create view, create trigger) 3 (oder waren es 4?) Generatoren geschrieben.

    In der Summe nicht aufwandsfrei, aber signifikant weniger als Umstellung der vorhandenen Anwendung auf Unicode und wichtiger: Keinerlei Risiken für die vorhandene Anwendung (mit ihrem unbekannten Anteil an Varianten)

    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/

  10. #22
    Registriert seit
    Aug 2014
    Beiträge
    179
    Ich habe einen Webservice zum Klicken gebaut, der Daten in Tschechisch, Russisch und Chinesisch als Webservice ausgibt. Als Frontend kann man jedes beliebige Webframework benutzen www.myhofi.com/muscgip/mymustst.pgm

    Die Datei ist wie folgt aufgebaut:

    HTML-Code:
    create or replace table mylib.myfile (                                                                            
             id       int generated always as identity (start with 1 increment by 1),                                               
             artist1  char(50)    ccsid 1208,                                                                         
             artist2  graphic(50) ccsid 1200,                                                                         
             artist3  graphic(50) ccsid 13488,                                                                        
             primary  key(id)                                                                                       
            )
    Mit wenigen JavaScript Statements ist es z.B. mit www.webix.com möglich, eine Weboberfläche für einen Webservice zu bauen
    www.myhofi.com/devhtm/Websrv04.html

    HTML-Code:
    //--------------------------------------------------------------------------//
    // Main                                                                     //
    //--------------------------------------------------------------------------//
    
    webix.ready(function(){
        webix.ui({
            view: "datatable",
            id: "myTable",
            autoConfig: true
        });
        webix.extend($$("myTable"), webix.ProgressBar);
        readData("myTable");
    });
    
    //--------------------------------------------------------------------------//
    // Read Data                                                                //
    //--------------------------------------------------------------------------//
    
    function readData(tableId) {
        $$(tableId).showProgress({hide:true});
        webix.ajax().post("/myapp/websrv01.pgm", {id:0},
            function(text, data) {
                $$(tableId).clearAll();
                $$(tableId).parse(data.json().items);
                $$(tableId).setPage(0);
                $$(tableId).hideProgress();
            }
        );
    }
    Den Sourcecode für die Webservices findet ihr hier https://github.com/rainerross/websrvutl

    Viele Grüße
    Rainer

  11. #23
    Registriert seit
    Jan 2012
    Beiträge
    1.102
    Auch an dich vielen Dank, Rainer. Noch mal eine vielleicht naive Frage: Wir haben bisher ja alle Felder in unseren Tabellen im SBCS (Also Single Byte Character Set) definiert. Gibt es einen "globalen Schalter", mit dem man alles (also alle Felder in allen Tabellen) auf Unicode umstellen könnte? Das System müsste dann, vereinfacht gesagt, ja nur alle Speicherplätze verdoppeln.

  12. #24
    Registriert seit
    Feb 2001
    Beiträge
    20.207
    Also ja und nein:
    Wenn du alle Dateien mit DDS erstellt hast und diese grundsätzlich mit einer REFF definierst, musst du nur die REFF anpassen.
    Hast du keine REFF must du die Felder anpassen. Anschließend alle Dateien mit CHGPF umsetzen. Die Daten bleiben dabei erhalten.

    In SQL gibt es das leider so nicht. Hier gibts es nur einen "Create or Replace", wobei dann eben alle Daten weg sind. Du musst dann halt Sripte erstellen, die statt dessen einen "Alter Table ... Alter Column set data-type ..." generieren.
    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

Berechtigungen

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