Zeitfeld aus SQL umwandeln in "deutsches" Zeitformat

[dschroeder]

Hallo,
nur eine Kleinigkeit. Ich schreibe gerade eine SQL Funktion, die ein Datumsfeld und ein Zeitfeld an ein RPGLE-Programm übergibt. Da SQL ja alles in ISO macht, empfängt das RPG-Programm das Datum als *ISO und schiebt es dann weiter in ein Datumsfeld, das *EUR definiert ist. (*EUR ist bei uns der Standard). Klappt wunderbar.

Mit dem Zeitfeld habe ich allerdings mehr Probleme. Das Zeitfeld in meinem RPG-Programm ist *HMS definiert. Dort steht z.B. "13:34:55" drin. SQL übergibt das aber mit Punkten anstatt mit Doppelpunkten: "13.34.55". Bei der Zuweisung in ein *HMS Feld knallt es dann!

Muss ich das echt über Alpha-Felder machen oder gibt es da eine elegantere Lösung?

Im Voraus Danke,

Dieter.

[Fuerchau]

Gib in den SQL-Options "exec sql set option ...;" das gewünschte Datum- und Zeitformat an, dann liefert SQL auch das so wie du willst. Hier kannst du auch problemlos in *EUR arbeiten und benötigst keine Zwischenfelder mehr.

Nachtrag:
Intern im Programm solle man besser mit *ISO arbeiten, dann klappen auch Vergleiche besser.
Nur bei der Ausgabe (DSPF, PRTF) kannst du dann *EUR angeben. Die Konvertierung erfolgt automatisch.

[dschroeder]

Vielen Dank!
In mehr als 20 Jahren sind alle Date Felder in unseren Anwendungen *EUR. Das können wir heute nicht mehr ändern.
Ich bin noch sicher, ob wir die Options in der SQL-Funktion einsetzen können. Die Funktion besteht im Prinzip nur aus einer SQL-Anweisung, die das RPGLE-Serviceprogramm einbindet. Ich werde mal schauen, ob es da solche Datums- und Zeit-Optionen gibt.

Ich dachte immer, SQL würde Datumsfelder immer im *ISO Fomat verarbeiten. Würde ein "set options" da wirklich helfen?

Ich probiere es mal aus.

[B.Hauser]

SQL übergeibt im ISO-Format, also mit Punkten als Trennzeichen. Warum machst Du nicht die gleiche Konvertierung wie mit dem Datums-Feld, von ISO nach EUR?
Alternativ kannst Du auch beim HMS das (abweichende) Trennzeichen anfügen.

Mit EXEC SQL wird nur bestimmt in welchem Format die zusätzlichen Hilfsvariablen für embedded SQL definiert werden.
SQL selber interessiert das Datums-Format nicht. Das Datums-Format wird nur zur Anzeige der Scallinger Nummer benötigt, wofür das Job-Format herangezogen wird.
Wird allerdings von SQL ein Datum als Parameter übertragen, erfolgt die Übergabe via Reference und wird als ISO-Format interpretiert.
Im Gegensatz zu RPG-Prozeduren, bei denen das Datums-/Zeit-Format im Prototypen (und Procedure-Interface) angegeben werden kann und im Anschluss eine entsprechende Konvertierung erfolgen kann, gibt es diese Möglichkeit bei SQL nicht.

Birgitta

Birgitta

[dschroeder]

Hallo Birgitta,
danke für die Antwort. Ich wollte mit dem Zeitfeld ja genauso verfahren, wie mit dem Datumsfeld. Also im Eingangsparameter das Zeitfeld als ISO definieren und dann in ein neues Zeitfeld übertragen, das als Format *HMS hat. Bei dieser Übertragung kommt es aber leider zu einem Fehler.

Ich werde das gleich aber nochmal probieren. Nicht dass ich da irgendeinen Tippfehler gemacht habe.

[Fuerchau]

Warum wird eigentlich immer der selbe Mist erzählt?
"SQL selber interessiert das Datums-Format nicht. Das Datums-Format wird nur zur Anzeige der Scallinger Nummer benötigt, wofür das Job-Format herangezogen wird."
Du musst unterscheiden zwischen der Datenbank, die ein Datum/Zeit/Zeitmarke in einer internen Form speichert.
SQL ist aber die Schnittstelle zwischen Datenbank und Programm (auch STRSQL ist ein Programm).
Hier ist sehr wohl das Datumformat wichtig, damit ein Programm mit dieser Art Information umgehen kann.
Ich habe dir schon mal die Frage gestellt, wie ich dann SQL-technisch diese "Scallinger Nummer" abfragen oder auch setzen kann. Bisher bist du mir da die Antwort schuldig geblieben.
SQL akzepiert für ein Datumsfeld auschließlich ein gültiges Datum in einem Datumsformat.

Per "set option datfmt = *EUR" werden die internen Hostvariablen, da hast du Recht, in *EUR definiert.
Somit übergibt SQL ein Datum in EUR.
Die RPG-Runtime konvertiert dann das Datum in das Zielformat, dass dann durchaus abweichend sein kann und bei z.B. *DMY durchaus Laufzeitfehler auslösen kann.

Und sicherlich kann ich in SQL ein Datum in beliebige andere Formate konvertieren:
char(mydate, *iso | *usa | *jis)
Was fehlt sind halt Formate wie DMY, aber da kann ich dann auch in SQL eigene Konvertierungen machen in dem ich die Extractfunktionen YEAR(), MONTH(), DAY() verwende und das Datum anders zusammenschuster.

Immerhin widersprichts du dir da selber:
"Mit EXEC SQL wird nur bestimmt in welchem Format die zusätzlichen Hilfsvariablen für embedded SQL definiert werden."
"Wird allerdings von SQL ein Datum als Parameter übertragen, erfolgt die Übergabe via Reference und wird als ISO-Format interpretiert."
Wenn du dir die Spoolauflösung ansiehts, so wird in der ersten Ebene das definierte Format an SQL übergeben. Dass letztendlich dann die Datenbankebene (hinter SQL) in die interne Form umwandelt ist ja selbst verständlich.
Denn schließlich wird mit auch beim DSPPFM das Datum in Klartext angezeigt.

Definierst du in den Options *EUR musst du in Hostvariablen (also Parametern) natürlich ein Datum in *EUR übergeben. Wobei dies nun durch die RPG-Runtime aufgelöst wird, denn schließlich ist die automatische Hostvariable ja mit *EUR definiert und der RPG-Move/Eval ruft dann die Konvertierung auf. Das hat wiederum nichts mit SQL zu tun.

[dschroeder]

Tja, was soll ich sagen: Jetzt funktioniert es. Ich muss vorgestern, als ich das Programm geschrieben habe, irgendetwas falsch geschrieben haben. Es klappt jetzt genauso, wie ich das geplant habe und wie Birgitta das auch beschrieben hat.

Sorry für diesen Thread.

Danke nochmal für alle Antworten.

Dieter

[Fuerchau]

Nachtrag:
Per "set option TIMSEP" bestimmst du den Trenner für das Zeitformat.
Default ist nun mal englisch.

[andreaspr@aon.at]

Warum wird eigentlich immer der selbe Mist erzählt?

Fängt das schon wieder an ...

[Fuerchau]

Nun, wenn man die Leute gerne verwirren möchte, kann man natürlich immer wieder die selbe unsinnige Information abgeben. Allerdings habe ich da 2 Möglichkeiten:
a) ich kann den Beitrag editieren und nur das wesentliche stehen lassen
b) ich kann es (zum wiederholten male) richtigstellen

Natürlich halte ich b) für die bessere Variante.
Immerhin könnte man ja bei Suchfunktionen durchaus auf diese Information stoßen und eine Richtigstellung halte ich da einfach für nötig.

Sobald Birgitta mir per SQL aufzeigt, wie ich ohne Datumformat mit der nativen Scaliger umgehen kann, werde ich Ruhe geben.
Aber es ist eben so, dass alle SQL-Zugriffe ein Datumformat definieren, selbst wenn ich keins angebe.

Sprachen wie Java/Net/VB o.ä., unterstützen native eine Datentyp "Date" der komplett ohne ein Format auskommt. Per Formatanweisung gebe ich dann die Ausgabe und per Convert-Anweisung die Eingabe an.
In ILERPG ist ein Date eine Zeichenvariable die speziell von der Runtime geprüft wird. Packe ich die in eine DS kann ich auch Unsinn reinstellen. Erst der Zugriff auf die Variable selber löst dann einen Runtimefehler aus.

[andreaspr@aon.at]

Nein, ich meine die Art WIE man das macht.

[B.Hauser]

Vielen Dank für die nette Zusammenarbeit!
Dies wird meine letzte Antwort in diesem Forum.

Verbreitet euern eigenen Mist wie Ihr wollt das ist mir zukünftig egal.

Den Mist den ich angeblich verzapfe habe ich mir gerade nochmal vom Lab Rochester bestätigen lassen.
... ach so, die Leute aus Rochester haben ja auch keine Ahnung wie ihre Datenbank funktioniert.

Die scaliger No kann man sich natürlich anschauen, indem man sich den Hex-Wert eines Datums anschaut. Das ist so trivial, dass man das wirklich nicht groß und breit erklären muss.
Schaut man sich den Hex-Wert vom 01.01.0001 an erhält man den Wert 001A4452. Also nicht etwa 1 oder 10101!
Der Hex-Wert 001A4452 entspricht numerisch 1721426.

Mit der Funktion JULIAN_DAY kann man die Anzahl der Tage seit dem 01.01.4713 v.Chr (Beginn des Julianischen Kalenders und Ausgangspunkt für die Scaliger No - kann man übrigens in der Referenz nachlesen).
Values(Julian_Day(Date('0001-01-01'))) ergibt 1721426!

Mich würde ja echt mal interessieren, wie man eine negative Scaliger No hinbekommt, wenn man sich diese noch nicht einmal anzeigen lassen kann.

Nein, mach Dir nicht die Mühe zu antworten, ich werde eine Antwort nicht mehr lesen.

In RPG wird die Scaliger No übrigens immer konvertiert und unmittelbar vor dem Zurückschreiben wieder zurückkonvertiert, so dass auch beim Debugg der Scaliger Wert nicht sichtbar ist. Wird in ein Datums-Feld mit einem Datums-Format mit 2-stelligem Jahr konvertiert, kann es zu Überläufen und Abbrüchen kommen. Nicht wegen der Scaliger No, sonder wegen des konvertierten Datums.
Diese Information stamm übrigens aus Toronto, ... ach ja die wissen ja auch nicht wie RPG funktioniert!

Birgitta