Datumsformat in *EUR bei einer SQL-Tabelle

[Tinabsd]

Hallo,

ich möchte eine SQL-Tabelle mit Datumsfeldern erstellen. Leider wird automatisch durch Angabe der Feldart "DATE" ein Datumsfeld mit Format *ISO erstellt. Da unsere Daten in *EUR "TT.MM.JJJJ" gespeichert werden, gibt es Datensalat oder unsere Programme fallen auf die Nase. Hat jemand eine Idee, ob es beim Anlegen der Felder ein Schlüssewort oder ähnliches gibt??

CREATE TABLE TAB551

( TABNR CHAR( 6 ) NOT NULL,
TABFLG DEC( 5, 0) NOT NULL,
TABDATVW DATE,
TABDATBW DATE,

Vielen Dank

[Fuerchau]

Nicht das Datenformat der Tabelle ist entscheidend (Date ist immer ein Datum), sondern das lesende Programm entscheidet über die Darstellung.

In ILERPG ist das Feld vom Typ 'D'.
D MyChar 10
D MyDate D

MyChar = %char(MyDate); // DATFMT entscheidet
MyChar = %char(MyDate:*EUR); // EUR-Format

Das selbe gilt für STRSQL (F13-Einstellungen), ODBC usw.

[B.Hauser]

Hallo,

kleiner Irrtum.
Ein Datum wird immer ohne Format erstellt, d.h. ein Datum ist ein 4-stelliger Binär-Wert, der die Anzahl der Tage seit Zeitpunkt x representiert. (Mit der Funktion HEX() kannst Du Dir mal die Hex-Werte anzeigen lassen.)

Das Datums-Format macht diesen Binär-Wert lediglich lesbar.

In welchem Datums-Format der Binär-Wert ausgegeben wird ist vom aktuellen Job abhängig.

Wenn Du mit interaktivem SQL arbeitest, kannst Du das Datums-Format über F13, Auswahl 1 einstellen.
Wenn Du mit dem iNavigator - Eine SQL Prozedur arbeiten/Run an SQL Script arbeitest, kann das Datums-Format über JDBC-Setup festgelegt werden.
In embedded SQL kann das Datums-Format im Compile-Befehl oder über ein SET OPTION-Statement festgelegt werden (Unterlassungs-Wert ist das Format des aktuellen Jobs).
In der SQL-Programmierung kann das Datums-Format ebenfalls über ein SET OPTION-Statement festgelegt werden.

Sollte das Ganze immer noch nicht ausreichen, kann man ein Datum über die Funktion CHAR in eine alphanumerische Darstellung in (fast) jedem beliebigen Format konvertieren:

Select Char(MyDate, EUR), a.*
From MyTable a 

Vielleicht noch eine Anmerkung:
Im Gegensatz zu SQL werden in RPG Datums-Felder IMMER konvertiert und erst vor dem Fortschreiben wieder in echte Datums-Formate ungewandelt.
Probleme mit dem europäischen Format kann es dann geben, wenn Datums-Felder im "falschen" Format an ein Programm oder eine Prozedur überegeben werden. Deshalb sollte man soweit möglich die Parameter-Felder mit dem Schlüssel-Wort CONST definieren und das Datums-Format im Prototpyen angeben.

Ansonsten hilft in RPG nur konvertieren:
--> Hilfs-Felder mit Datums-Format *EUR anlegen und umladen.

Übrigens in SQL ist das Format egal, da das Datum nicht konvertiert wird!
SQL kann sogar alphanumerische Darstellungen mit den Formaten 'JJJJ-MM-DD', 'TT.MM.JJJJ' und 'MM/TT/JJJJ' als Datum erkennen und automatisch in den Binär-Wert konvertieren.
Schlägt ein RPG-Programm mit embedded SQL mit einem Datums-Format-Problem auf, liegt es daran, dass der SQL-Precompiler für jede Hostvariable eine zusätzliche Variable anlegt. Bei Datums-Feldern erhält das Datum das Format, das im Compile-Befehl oder in der SET OPTION-Anweisung angegeben wurde. Der Abbruch erfolgt beim MOVE der Host-Variablen in die zusätzlich gebildeten Hilfs-Variablen.

Birgitta

[Tinabsd]

Hallo Birgitta,

leider haben wir zig RPG-Programme, die in folgende H-Anweisung haben:
H DATEDIT(*DMY.) DATFMT(*EUR)
Diese Programme können mit der neu angelegten Tabelle leider nicht umgehen.

[Fuerchau]

Ich denke, da liegen die Probleme eher anderswo.
Die Felder werden automatisch korrekt definiert, aber wie gehen die Programme denn damit um ?

[Tinabsd]

Sämtliche Tabellen wurden als DDS-Tabellen erstellt. Die Datumsfelder beziehen sich auf ein Feld in einer Feldreferenzdatei, welches so definiert wurde: "L"=Datenart für Datumsfelder
DATUM L DATFMT(*EUR)
DFT('01.01.0001')
COLHDG('Datum ')

Legen wir nun SQL-Tabellen an, müssen diese teilweise zusammen mit den DDS-Tabellen verwendet werden.


Vielen Dank

[Fuerchau]

Das spielt doch überhaupt keine Rolle.
DATFMT(*EUR) dient nur für die Referenz in DSPF/PRTF und nicht für PF.
Das DATFMT kann auch weggelassen werden, die PF wird trotzdem korrekt erstellt.

Noch mal meine Frage:
Wo genau ist das Problem im RPG-Programm ?
Es kann nicht mit dem DATFMT zu tun haben !

[Tinabsd]

Bei der Ausführung eines bereits bestehenden RPG-Programms mit Zugriff auf die SQL-Datei bekomme ich folgende Systemnachricht:
Nachricht . . . : Datenzuordnungsfehler in Teildatei TAB551.
Ursache . . . . : Bei Feld TABDATVW im Satz mit Nummer 0 und Format TABNNF
in Teildatei TAB551 mit Nummer 1 der Datei TAB551 in Bibliothek BASD_S ist
wegen Fehlercode 17 ein Datenzuordnungsfehler aufgetreten. Fehlercodes und
ihre Bedeutung:

17 - Format der Daten in einem Datums-, Zeit- oder Zeitmarkenfeld ist ungültig.

Vielleicht drücke ich mich nicht richtig aus...sorry!

Tinabsd

[Fuerchau]

Ich nehme mal an, dies passiert beim Schreiben (beim Lesen kann der Fehler eigentlich nicht kommen) und deutet auf eine fehlerhafte Initialisierung des Feldes hin.
Ich würde da mal einen Dump machen und den Inhalt prüfen.

[BenderD]

Mit dem huddel (für den du nix kannst, sondern die Entwickler des RPG Compilers verantwortlich sind) ist das so, wie mit null oder 0 und dem multiplizieren. Sobald an einer Operation null beteiligt ist, kommt null raus und sobald an einer Operation huddel beteiligt ist, kommt huddel raus.
Das DATFMT bei Feldern (kann man sich mit DSPFFD ansehen) ist eben nur fast Banane, sondern wird bei externen Datenstrukturen mitgenommen auf die entsprechenden Felder, was bis hierhin noch nix macht. Wird jetzt so ein Feld mit einer nicht typsicheren Operation angefasst, (Übergabe als Parameter by reference, Überlagerung per Overlay, Zuweisung einer Datenstruktur an eine andere, Substring Operationen) dann kann man zwei Datumsfelder aufeinander knebeln, die nicht aufeinander passen, was dann bei der nächsten typsicheren Operation (zum Beispiel schreiben in die Datenbank) schief geht.
PTF: not available
Work arounds:
- you must not use huddle features of the Compiler
(overlay, call by reference, eval appleDS = pearDS etc.)
- alles *ISO machen (auch per View Layer!)

D*B

Bei der Ausführung eines bereits bestehenden RPG-Programms mit Zugriff auf die SQL-Datei bekomme ich folgende Systemnachricht:
Nachricht . . . : Datenzuordnungsfehler in Teildatei TAB551.
Ursache . . . . : Bei Feld TABDATVW im Satz mit Nummer 0 und Format TABNNF
in Teildatei TAB551 mit Nummer 1 der Datei TAB551 in Bibliothek BASD_S ist
wegen Fehlercode 17 ein Datenzuordnungsfehler aufgetreten. Fehlercodes und
ihre Bedeutung:

17 - Format der Daten in einem Datums-, Zeit- oder Zeitmarkenfeld ist ungültig.

Vielleicht drücke ich mich nicht richtig aus...sorry!

Tinabsd

[Fuerchau]

Datumsfelder in RPG (nicht ILE) werden ja als Zeichenfelder (10) dargestellt. In diesem Fall ist das Datumformat natürlich wichtig, da der Compiler intern den Feldwert anpassen muss.

Im ILE-RPG gibts deshalb den Typ "D" und nicht als Zeichen, dann funktioniert das mit dem DATE ohne Probleme, egal was für ein DATFMT du hast.

Mein Vermutung geht eben dahin, dass du das Datum-Feld nicht als D definiert hast, und deshalb bei der SQL-Tabelle das Problem bekommst.

Auf neue SQL-Tabellen kannst du ggf. keine alten RPG's loslassen.

Alternative:
Erstelle die Tabelle per DDS wie gewohnt damit die alten Programme damit zurechtkommen.

[BenderD]

@Baldur: schau dir mal die Umwandlungsliste an, was die bei einer externen Datenstruktur so macht...

Im ILE-RPG gibts deshalb den Typ "D" und nicht als Zeichen, dann funktioniert das mit dem DATE ohne Probleme, egal was für ein DATFMT du hast.