SQL Auto Increment

[BenderD]

... bei normalisierten Daten umfasst ein insert aus Programmsicht mehrere inserts in die Datenbank, bei denen man oft die soeben geschriebenen Schlüssel für andere Tabellen als Foreign Key benötigt.

D*B

finde diese off-topic beiträge recht interessant :-)

verstehe grad nicht, was da gemeint wurde.
wenn 2 tabellen miteinander per FK verknüpt werden, muss immer zuerst die ID ermittelt werden bevor sie referenziert wird.
da ist es ja egal, ob der key vom programm oder der DB generiert wird.

[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.

[kitvb1]

...

...
exec sql set option commit=*none;
...

SET OPTION muss der erste Befehl sein den Du ausführst.

[andreaspr@aon.at]

SET OPTION muss der erste SQL-BEFEHL sein der ausgeführt werden muss, und das ist in dem vorherigen beispiel der fall.

[B.Hauser]

Korrektur:

SET OPTION muss der erste Befehl sein den Du ausführst. 

SET OPTION wird überhaupt nicht ausgeführt!
SET OPTION sind Compiler-Anweisungen und müssen deshalb (so ist halt der SQL-PreCompiler implementiert) physisch in der Quelle vor allen anderen SQL-Statements stehen!

Würde SET OPTION in der *INZSR stehen, die am Ende der Quelle steht und alle anderen SQL Statements wären im Hauptprogramm, gäbe es (oder zumindest gab es) einen Compile Fehler.

Ich muss mal wieder prüfen, ob es inzwischen nicht ein PTF gibt, das auch eine Definition an einer anderen Stelle zulässt.

Birgitta

[Kurmas Zeschlon]

Danke für die Tipps! Ich habe es nun wie in Birgittas Beispiel versucht.

Das Statement sollte funktionieren, wenn Du die Union-Anweisung als Sub-Select definierst.

Etwa so:

insert into LastTable (DNr, Dlabel, DName)
      (Select Next Value for Seq_Zaehler, x.*
         From (Select FldLabel, FldName from MyTable
                 Union All 
               Select XYZLabel, XYZName from NextTable) x 

Birgitta

Das einzige Problem, das ich noch hatte, war, dass die Sequenz bei jedem Programmaufruf wieder bei 1 anfangen soll.

Das habe ich nun so gelöst:

exec sql drop sequence seq_zaehler;
exec sql create sequence seq_zaehler start with 1 increment by 1 no maxvalue order; 

Es funktioniert, aber ist es auch eine gute Idee?

Nochmals vielen Dank an euch!
Markus

[Fuerchau]

Einfacher gehts mit

ALTER SEQUENCE

MySequence RESTART