Ändern von Datensätzen

[dino]

Hallo *all,
Gibt es eine Möglichkeit, auf Satzebene Änderungstag/-Zeit abzugragen, z.B. Änderung per SQL oder DFU?

[BenderD]

... STRJRNPF ist dein Freund

D*B

Hallo *all,
Gibt es eine Möglichkeit, auf Satzebene Änderungstag/-Zeit abzugragen, z.B. Änderung per SQL oder DFU?

[andreaspr@aon.at]

es gibt ab V6R1 die möglichkeit, in tabellen eine spalte zu definieren (TIMESTAMP), welche automatisch das datum der letzten nderung (update/insert) gesetzt bekommen. diese spalte kann dann auch noch als hidden-feld definiert werden, sodass es zb beim Select * From ... nicht mit ausgegeben wird.

lg andreas

[B.Hauser]

es gibt ab V6R1 die möglichkeit, in tabellen eine spalte zu definieren (TIMESTAMP), welche automatisch das datum der letzten nderung (update/insert) gesetzt bekommen. diese spalte kann dann auch noch als hidden-feld definiert werden, sodass es zb beim Select * From ... nicht mit ausgegeben wird.

lg andreas

Das Ganze hat nur noch? die folgenden Probleme:
Zwar ist in der Dokumentation beschrieben, dass die Zeitmarke automatisch, unabhängig vom verwendeten Interface (SQL, Native I/O, UPDDTA ...) funktionieren soll, Tatsache ist jedoch, dass dies aktuell nur für SQL gilt (und nicht z.B. für Native I/O!)

Wenn SELECT * in einem embedded SQL-Programm verwendet und in eine externe Datenstruktur, die mit EXTNAME definiert wurde ausgibt, gibt es ein Problem, da SELECT * die hidden Felder nicht ausgibt, die Datenstruktur jedoch alle Spalten beinhaltet. (Wieder ein Grund nicht select * zu verwenden).

Eine andere Möglichkeit wäre einen Before Inser/Update Trigger zu implementieren und die Zeitmarke über den Trigger zu setzen.

Birgitta

[andreaspr@aon.at]

Ist ja interessant. wie heist's so schön: man lernt nie aus.

[ExAzubi]

Würde auch einen Trigger vorschlagen, finde diesen einfacher zu "warten" als STRJRNPF.

[andreaspr@aon.at]

Wenn SELECT * in einem embedded SQL-Programm verwendet und in eine externe Datenstruktur, die mit EXTNAME definiert wurde ausgibt, gibt es ein Problem, da SELECT * die hidden Felder nicht ausgibt, die Datenstruktur jedoch alle Spalten beinhaltet. (Wieder ein Grund nicht select * zu verwenden).

das thema ist zwar schon alt, jedoch ist mir beim lesen in den SQL-referenzen dazu was eingefallen.
es gab ja in sql schon immer (oder zumindest sehr lange) die zusatzangabe von ALL im select

Select All * from MyTab

hatte jedoch bis v5r4 keine auswirkungen.
ab 6.1 werden mit Select All auch alle hiddenfelder ausgegeben.
wenn also in 6.1 hiddenfelder angegeben sind und das ergebnis aus einem SELECT in eine datenstruktur ausgeben werden möchte, sollte ein SELECT ALL * FROM MyTab reichen und es funktioniert.
wie es sich mit native I/O verhält, weis jedoch nicht.

[B.Hauser]

@Andreas,

hast Du das ausprobiert oder vermutest Du das nur?
(Ich kann es erst heute Abend ausprobieren, da ich aktuell kein Zugriff auf eine 6.1 Maschine habe)
... die Dokumentation lässt zumindest auf etwas anderes schließen:

ALL:
Selects all rows of the final result table and does not eliminate duplicates. This is the default.

DISTINCT:
Eliminates all but one of each set of duplicate rows of the final result table. Two rows are duplicates of one another only if each value in the first row is equal to the corresponding value in the second row. (For determining duplicate rows, two null values are considered equal.) The collating sequence is also used for determining distinct values. DISTINCT is not allowed if the select-list contains a DATALINK column.

Select list notation *:
Represents a list of columns of table R in the order the columns are produced by the FROM clause. Any columns defined with the hidden attribute will not be included. The list of names is established when the statement containing the SELECT clause is prepared. Therefore, * does not identify any columns that have been added to a table after the statement has been prepared.

Birgitta

[andreaspr@aon.at]

nein leider, ich lese und rede zwar viel über 6.1 aber habe bis auf wenige male keine möglichkeit gehabt dies auch zu testen, da mir die maschiene fehlt
mein wissen in diesem fall bezieht sich auf eine IBM-seite IBM DB2 for i 6.1 -- Sophistication simplified.
ich gehe jedoch einmal davon aus, dass das ergebnis im embedded sql das gleiche sei.

[Fuerchau]

ALL und DISTINCT gab es schon immer, wobei ALL im Select der Default ist, deshalb hat ALL eben keine direkten Auswirkungen.
Im Gegensatz zu UNION, da ist DISTINCT zwar nicht anzugeben aber der Default um doppelte Sätze zwischen den Select's auszuschließen:
select [ALL/DISTINCT] ...
union [ALL]
select [ALL/DISTINCT] ...

Mit den Hidden-Feldern hat das nichts zu tun.
Wobei ich mich frage, wozu hidden Felder gut sein soll, außer, dass sie bei select * nicht automatisch kommen sondern explizit angegeben werden müssen.

[BenderD]

...
die Doku ist da schon eindeutig.
- SELECT ALL (ist default := darf man weglassen, mit Duplikate)
- SELECT DISTINCT (hau weg die doppelten := alle Felder gleich)
- select * (alle Felder - außer hidden)
- select hugo, otto, carola, versteckMich (hier können auch hidden Felder stehen)
Wenns so funkt ist alles OK
funzts nicht, ist das kein Feature, sondern ein Bug.

D*B

[BenderD]

... wer fragt sich schon wofür ein Auto gut sein soll, außer dass man damit fahren kann...

Dieter
PS: naja, das Auto muss ja auch kein Suff oder SCHMART sein...

Wobei ich mich frage, wozu hidden Felder gut sein soll, außer, dass sie bei select * nicht automatisch kommen sondern explizit angegeben werden müssen.