create table mit timestamp

[Peet]

Hallo zusammen,
bisher habe ich mit DDS physische Dateien erstellt und dabei auch Felder für timestamp
definiert.
Das gleiche wollte ich jetzt mit create table machen, kann aber ein RPG nicht wandeln, weil
mein Statement im RPG nicht mehr funktioniert.
Beispiel:
PF mit DDS..


im RPG fülle ich das Feld dann...
asptimsn = %timestamp();

Wie muss ich das Feld mit create table definieren, damit ich es im RPG mit %trimestamp() füllen kann ???
create table worklib.wrkfile
( xxkey char(5)
, xxtimsn timestamp
)

Einfach mit Angabe "timestamp" als Art ???
...das hat bei mir nicht funktioniert, als ich das RPG umwandeln wollte
Danke im Voraus.

Vg.

[dschroeder]

Eigentlich sieht das bei dir gar nicht schlecht aus, denke ich. Hier mal ein Beispiel, wie
ich Tabellen erstelle:

create or replace table eddatlib/daxdatar (
rt_rec_id  decimal(15)    generated by default as identity,
rt_kennung char(100)      not null with default,
-- Protokollfelder:
rt_erfusr  char(10)       not null with default,
rt_erfts   timestamp      not null with default current_timestamp,
...
constraint eddatlib/daxdatar_pk primary key( rt_rec_id ) )
rcdfmt daxdatr1

Wenn das nicht hilft, müsstest du mal genau sagen, welchen Compilefehler du bekommst.

Hast du vielleicht kein Record-Format angegeben?

[B.Hauser]

Was für einen Fehler bekommst Du denn überhaupt?

Die Definition mit Timestamp ist korrekt ... und dieses Feld kann man auch mit %Timestamp() füllen.

Ich würde allerdings bei einer Arbeitsdatei in RPG die Felder immer als NICHT NULL-fähig definieren, also:
NOT NULL Default-Wert.

Kleiner Tipp mit ACS GENERATE_SQL bzw. mit der Stored Procedure GENERATE_SQL kannst Du Dir direkt aus einer physischen Datei den CREATE (OR REPLACE) Befehl generieren.

[Peet]

Was für einen Fehler bekommst Du denn überhaupt?

Die Definition mit Timestamp ist korrekt ... und dieses Feld kann man auch mit %Timestamp() füllen.

Ich würde allerdings bei einer Arbeitsdatei in RPG die Felder immer als NICHT NULL-fähig definieren, also:
NOT NULL Default-Wert.

Kleiner Tipp mit ACS GENERATE_SQL bzw. mit der Stored Procedure GENERATE_SQL kannst Du Dir direkt aus einer physischen Datei den CREATE (OR REPLACE) Befehl generieren.

Danke Birgitta
Den Umwandlungsfehler habe ich nicht mehr auf dem Schirm.
Wenn er wieder auftritt, schreibe ich nochmal.
Vg.

[Fuerchau]

NULL-fähige Felder sind auch in ILERPG durchaus zulässig.
Denn bei NOT NULL ist der Default zufällig Current Timestamp was auch nicht immer sinnvoll ist. Man muss den Default dann tatsächlich auf "0001-01-01 00.00.00.000000", bei ISO, festlegen um ihn in ILERPG mit *LOVAL ansprechen zu können.
Wenn ich lt. obigen Beispiel noch ein rt_chgts benötige halt ich current timestamp für nicht zielführend.
Auch wenn ich in SQL arbeite ist eine Abfrage "is null" einfacher als "= timestamp('0001-01-01 00.00.00.000000')".

Aber Programmierung eralubt halt viele Wege.

[B.Hauser]

Natürlich kann man in RPG auch mit NULL-fähigen Feldern arbeiten selbst mit Native I/O (etwas anderes habe ich auch nie behauptet), es ist nur aufwändiger.
NULL-Werte sind Werte außerhalb des gültigen Bereichs, also wenn ich alle Werte zwischen *LOVAL und *HIVAL selektiere, werden die Datensätze, die NULL-Werte enthalten nicht ausgewählt, also ist eine zusätzliche Prüfung erforderlich.
Werden NULL-Werte aus einem SQL-Statement heraus zurückgegeben, muss ich ich RPG entweder mit Indikator-Variablen arbeiten, und jede Indikator-Variable prüfen (bei NULL-Werten werden i.Ü. die Host-Variablen nicht intialisiert!) oder ich muss jede einzelne Spalte, die einen NULL-Wert enthalten könnte, mit COALESCE so verändern, dass ein NULL-Wert in einen Default-Wert konvertiert wird.
Da NULL-Werte extra geprüft werden müssen, ist das auch ein zusätzlicher Aufwand, die (wenn auch nur im Nano-Sekunden-Bereich) die Performance beeinträchtigen kann.

[Fuerchau]

"bei NULL-Werten werden i.Ü. die Host-Variablen nicht intialisiert!"
Das ist definitiv falsch, dies gilt nur für Date/Timestamp-Variablen.
Denn die Evals der Einzelfelder werden beim Fetch alle ausgeführt, schau dir den generierten Code an!
Nur bei den o.a. Typen gibts halt kein Loval-Ergebnis, da das bei bestimmten DateTime-Formaten (2-stelliges Jahr) nicht definiert ist und zu RPG-Laufzeitfehlern führt.
Wie i.Ü. auch beim 1.1.0001 und 2-stelligem Jahr Zielfeldern.