SQL Auto Increment

[andreaspr@aon.at]

ich verstehe da nur noch immer nicht das problem?
ist ja doch ganz normal.

[B.Hauser]

Ich kann das Problem eigentlich auch nicht nachvollziehen.

Arbeitet man mit Identity Columns und fügt einen einzelnen Satz mit SQL oder native I/O ein, kann man der eingefügten Identity-Wert mit dem SQL Befehl Identity_Val_Local ermitteln.
Dabei ist es unerheblich, wie der Satz erzeugt wurde (SQL oder Native I/O). Das der Job und innerhalb des Jobs das Job-Level wird berückichtigt, d.h. auch wenn durch einen anderen Job oder einen Trigger ein weiterer Datensatz hinzugefügt wurde, wird der Wert des vorhergehenen Inserts oder Writes ermittelt.

Bei Sequences ermittelt man den Wert zuerst und schreibt dann.

Werden bei einem SQL Insert mehrere Sätze eingefügt, kann man die soeben eingefügten Datensätze (ab 6.1) mit allen (generierten) Werten wie folgt ermitteln. Das Insert-Statement wird innerhalb eines Select-Statements ausgeführt.
z.B.

'
Select HdrId, OrderNo
  From Final Table(Insert OrderHdr(OrderNo,  CustNo,  DelTerms, 
                                   DelDate, OrderType) 
                          Select IFORDN,     IFCUST,  IFDELT,
                                 Date(Digits(IFDELT concat '000000',
                                 IFORDT)
                              From  Interface
                             Where IFSTAT = ' ')
Order By Input Sequence 

Birgitta

[BenderD]

... alles viel komplizierter als vorher getNextKey(Dateiname) aufzurufen und den Key zu belegen und last not least sind diese ganzen Features nicht ANSI SQL und damit rate ich davon ab!
Wer sich lieber an DB2/400 bindet, mag das tun.

D*B

Ich kann das Problem eigentlich auch nicht nachvollziehen.

Arbeitet man mit Identity Columns und fügt einen einzelnen Satz mit SQL oder native I/O ein, kann man der eingefügten Identity-Wert mit dem SQL Befehl Identity_Val_Local ermitteln.
Dabei ist es unerheblich, wie der Satz erzeugt wurde (SQL oder Native I/O). Das der Job und innerhalb des Jobs das Job-Level wird berückichtigt, d.h. auch wenn durch einen anderen Job oder einen Trigger ein weiterer Datensatz hinzugefügt wurde, wird der Wert des vorhergehenen Inserts oder Writes ermittelt.

Bei Sequences ermittelt man den Wert zuerst und schreibt dann.

Werden bei einem SQL Insert mehrere Sätze eingefügt, kann man die soeben eingefügten Datensätze (ab 6.1) mit allen (generierten) Werten wie folgt ermitteln. Das Insert-Statement wird innerhalb eines Select-Statements ausgeführt.
z.B.

'
Select HdrId, OrderNo
  From Final Table(Insert OrderHdr(OrderNo,  CustNo,  DelTerms, 
                                   DelDate, OrderType) 
                          Select IFORDN,     IFCUST,  IFDELT,
                                 Date(Digits(IFDELT concat '000000',
                                 IFORDT)
                              From  Interface
                             Where IFSTAT = ' ')
Order By Input Sequence 

Birgitta

[Fuerchau]

Was nützen mir die Features von V6, wenn ich z.T. noch mit V5R2 arbeiten muss.
NEXT VALUE gab es da allerdings auch schon und das Problem der Foreign Keys gibt es da auch schon.
Sequences und Identities sind ja auch ganz nett erhöhen aber nun mal den Programmier- und Wartungsaufwand. Fehlerquellen sind da schon vorprogrammiert.

In properitären Anwendungen wurden ja damals schon Tabellen mit Zählschlüsseln verwaltet, für die man nun nachträglich auch noch Dieters getnextkey() entwicklen kann um somit Masseninserts (insert ... select) problemlos realisieren zu können.

Was mir bei den Identities und Sequences nicht so gut gefällt ist die Cache-Funktion, die mir Nr'n verbrät und die ich gezielt abschalten muss (zu Lasten der Performance), der Default ist 20.

[andreaspr@aon.at]

ich behaupte dass weder die eine methode noch die andere kompliziert sei.
die frage ist vielmehr eine geschmackssache.

und was das ANSI SQL betrifft:
ab 6.1 gibt es zumindest die möglichkeit vom OS das SQL auf ANSI SQL prüfen zu lassen.
ich kenne aber sowieso keine (größere) datenbank die nicht features hat, welche nicht ANSI SQL sind. was meiner meinung egal ist, da man nie auf die idee kommen würde/sollte zb:
die datenbank eines Lagerverwaltungssystems von DB2 auf oracle umzustellen.

und zu sequences und identities:
ich weis nicht wie damit sonst noch programmiert wird, aber einen mehraufwand habe ich bis jetzt noch nie gehabt.