-
CPYTOIMPF mit String-Konstanten
Hallo,
ich bin schon oft auf dieser Seite gelandet, wenn ich technische Fragen zur AS400 hatte und habe auch meistens die passende Lösung gefunden.
Es gibt viele Einträge zu CPYTOIMPF, aber ich habe nix mit String-Konstanten gesehen. Daher frage ich mal:
Ich habe eine Tabelle per WRKQRY erstellt. Einige Felder sind String-Konstanten. Wenn ich diese Tabelle per CPYTOIMPF bereitstelle, dann sind nur die Felder, die per Konstante gefüllt sind, binär in der CSV-Datei. Der Rest ist komplett in Ordnung in der Windows-Codepage 1252 hinterlegt.
Der Befehl sieht so aus:
CPYTOIMPF FROMFILE(LIB/FILE) TOSTMF('path/name.csv') MBROPT(*REPLACE) STMFCCSID(*PCASCII)
Vielen Dank für Eure Unterstützung!
Michael
-
Das liegt wahrscheinlich am WRKQRY.
Sieh mal mit DSPFFD FILE(LIB/FILE) nach,
in welcher CCSID (ID des codierten Zeichensatzes) diese Felder sind.
-
Hallo Pikachu,
vielen Dank für die superschnelle Antwort! Tatsächlich haben die Felder, die konstant sind, die Zeichensatz-ID 65535 und alle anderen Felder die ID 273.
Das ist also mein Problem. Wie kann ich WRKQRY davon überzeugen, die Zeichensatz-ID 273 auch zu verwenden?
Wenn ich WRKQRY starte, steht auch im Header der Anwendung die CCSID 65535. Dafür habe ich keine Option gefunden.
Ich werde alternativ mal eine neue Tabelle anlegen (per SQL) und diese dann von WRKQRY nur befüllen lassen. Melde mich morgen, sobald das gelaufen ist.
Viele Grüße
Michael
-
Dann fährt dein Job (wieder mal) in Hex statt 273.
Dies gilt übrigens auch zur Laufzeit. Es nützt nichts, wenn du in 273 arbeitest, der Batchjob später aber wieder in Hex.
-
Die Verarbeitung erfolgt nach Ausführung eines Dialogprogramms innerhalb eines CL-Scripts, wird also nicht im Hintergrund automatisch gestartet. Wie ich hier die CCSID im Script ändern kann, habe ich noch nicht herausgefunden.
Als Lösung habe ich nun im CL-Script folgendes nach Ausführung der QRY und vor Ausführung von CPYTOIMPF eingebaut:
RUNSQL SQL('ALTER TABLE LIB.FILE ALTER COLUMN COL1 SET DATA TYPE CHARACTER(17) CCSID 273')
Das ist keine schöne Lösung, funktioniert aber zuverlässig. Lieber würde ich die CCSID im Script ändern, so dass WRKQRY die korrekte CCSID verwendet.
Vielen Dank für Eure schnelle Hilfe!
-
Wenn es ein CL-Programm ist, kannst Du die JOB CCSID über CHGJOB ändern (und auch wieder zurücksetzen).
Birgitta
-
Seit Jahren propagiere ich immer wieder, sein System auf die korrekte CCSID bereits im Systemwert einzustellen. 99,95% aller CCSID-Probleme entstehen dadurch erst gar nicht.
Trotzdem tauchen dieselben Probleme hier immer wieder auf weil die Systeme immer noch mit *HEX laufen (durch Auslieferung voreingestellt).
Spätestens seit Einführung von SQL muss man eine CCSID anwenden, da SQL sonst selbstständig eine ggf. unpassende CCSID auswählt (insbesonders bei ODBC/DRDA-Zugriffen).
-
Ok, das wusste ich nicht. Du hast natürlich Recht. In meinem Fall kann ich die CCSID nicht einfach umstellen, da ich die Auswirkungen erstmal für die gesamten Anwendungen testen müsste (bin seit ca. 3 Monaten im AS400-Umfeld tätig und kann das noch nicht abschätzen).
Bei einer Neuinstallation werde ich das definitiv zukünftig berücksichtigen.
Und beim ODBC-Zugriff hatte ich auch schon Spaß, allerdings gibt es im Treiber die Option "Binärdaten in Text umsetzen", dann klappt's.
-
Wenn ich die CCSID mit CHGJOB CCSID(273) umstelle, ist dem WRKQRY das scheinbar völlig egal. Oder die Information ist beim Speichern der Query mit abgelegt worden. Jedenfalls wird die neu erstellte Datei trotzdem mit 65535 für die konstanten Felder angelegt.
-
Solange man nicht mit echten Binärdaten auf der AS/400 umgeht, kann man mit der 65535-Umsetzung arbeiten. Ich speichere aber z.B. Bilder (jpg's usw.) in einer DB-Tabelle, da wäre diese Art der Umsetzung fatal, da damit die Bilder beim Lesen kaputt sind.
Bei mir wird die Ausgabedatei korrekt erstellt.
Allerdings hast du Recht, die CCSID oben rechts wird tatsächlich nur bei Neuerstellung gesetzt und kann nicht mehr geändert werden.
Fluch der bösen Tat...
-
Du hast mich auf die ideale Lösung gebracht, zusammen mit den anderen Informationen ist es nun imho perfekt .
Ich habe auf der Konsole CHGJOB CCSID(273) eingestellt, dann die QRY zweimal kopiert. Beim Kopieren übernimmt er die aktuelle CCSID und nun kann ich die CSV-Datei problemlos ohne ALTER-TABLE erstellen.
Das Wochenende kann nun kommen .
Similar Threads
-
By dschroeder in forum NEWSboard Programmierung
Antworten: 8
Letzter Beitrag: 16-05-17, 11:51
-
By ILEMax in forum NEWSboard Programmierung
Antworten: 6
Letzter Beitrag: 11-01-14, 09:32
-
By heynem in forum IBM i Hauptforum
Antworten: 9
Letzter Beitrag: 07-11-07, 11:53
-
By heynem in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 20-03-03, 09:15
-
By LaLeLi in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 19-06-02, 08:38
Tags for this Thread
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