SQL Auto Increment

[holgerscherer]

Soweit ich weiß heißt es ja auch schon nicht mehr V6R1M0 sondern offiziell (IBM) i 6.1 und das nächste wird dann IBM i 7.1

ja, IBM i 7.1 ist eher offiziell, aber das ist ein sehr schlechter Suchbegriff für die Suchmaschine. Da ist V7R1 oder R710 eher geeignet, und in vielen Dokumenten werden auch diese Strings verwendet

-h

[BenderD]

... zumindest bei Google ist das kein Problem!

Ergebnisse 1 - 10 von ungefähr 28.000 für V6R1M0.
Ergebnisse 1 - 10 von ungefähr 73.400.000 für i 6.1

=> Ziel erreicht: Bekanntheit signifikant gesteigert, obwohl der neuere Name noch garnicht auf allen Seiten aktualisiert ist

D*B

ja, IBM i 7.1 ist eher offiziell, aber das ist ein sehr schlechter Suchbegriff für die Suchmaschine. Da ist V7R1 oder R710 eher geeignet, und in vielen Dokumenten werden auch diese Strings verwendet

-h

[holgerscherer]

... zumindest bei Google ist das kein Problem!

Ergebnisse 1 - 10 von ungefähr 28.000 für V6R1M0.
Ergebnisse 1 - 10 von ungefähr 73.400.000 für i 6.1

Lach :-)

Wenn wir schon dabei sind:

V6R1 -> ungefähr 128.000
R610 -> ungefähr 778.000
i -> ungefähr 6.450.000.000 (na immerhin)
OS/400 -> ungefähr 15.100.000

Naja. Spass beiseite, ich kämpf noch ein wenig mit der Schweinegrippe rum...

-h

[Spateneder]

Schön, wie dieser Thread abgedriftet ist!
Mein Vorschlag, um den Bekanntheitsgrad noch einmal richtig voranzubringen: Das "i" (ich meine den unteren Strich) weglassen und nur noch den Punkt verwenden. Jeder Punkt gilt! Das wäre doch auch für Google eine schöne neue Aufgabe ... (und wieder drei Punkte)

[BenderD]

Ergebnisse 1 - 10 von ungefähr 6.390.000.000 für i
Es wurden keine mit Ihrer Suchanfrage - . - übereinstimmenden Dokumente gefunden.
Vorschläge: * Probieren Sie andere Suchbegriffe.

no comment

D*B

Schön, wie dieser Thread abgedriftet ist!
Mein Vorschlag, um den Bekanntheitsgrad noch einmal richtig voranzubringen: Das "i" (ich meine den unteren Strich) weglassen und nur noch den Punkt verwenden. Jeder Punkt gilt! Das wäre doch auch für Google eine schöne neue Aufgabe ... (und wieder drei Punkte)

[Fuerchau]

Um wieder zum Thema zurückzukommen:

Diverse Frameworks für Datenbankmodelle zur angeblich schnelleren Entwicklung von Business Objekten mit Datenhaltung, also Objekt-Hierarchie versus relationale DB, arbeiten fast ausschließlich mit SingleKeyes, 32/64-Bit am besten 128-Bit GUID's!
D.h, DB-Modelle wie "Mandant, Auftrags-Nr, Auftrags-Position" als Schlüssel werden gar nicht unterstützt.
Man muss also mit Identities arbeiten.
Ein nachträgliches Aufsetzen einer neuen Framework-Applikation auf bestehenden DB's wird somit zielgerichtet verhindert.

Man kommt also nicht umhin, neben seiner Applikation gleich auch noch das DB-Modell mit anzupassen.

Insofern sind Identities für zukunftige Entwicklungen wohl durchaus normal, wenn man nicht bei der alten zeilenweisen Programmierung verbleiben will .

[BenderD]

... der Punkt ist doch nicht ob man einen Primary Key hat und ob der einen semantischen Inhalt hat, sondern ob man sich den von der Datenbank generieren lässt, um ihn anschließend erst mal zu ermitteln, weil man ihn als Foreign Key für andere zu schreibende Tabellen benötigt - da steht doch jede Logik Kopf.

D*B

Um wieder zum Thema zurückzukommen:

Diverse Frameworks für Datenbankmodelle zur angeblich schnelleren Entwicklung von Business Objekten mit Datenhaltung, also Objekt-Hierarchie versus relationale DB, arbeiten fast ausschließlich mit SingleKeyes, 32/64-Bit am besten 128-Bit GUID's!
D.h, DB-Modelle wie "Mandant, Auftrags-Nr, Auftrags-Position" als Schlüssel werden gar nicht unterstützt.
Man muss also mit Identities arbeiten.
Ein nachträgliches Aufsetzen einer neuen Framework-Applikation auf bestehenden DB's wird somit zielgerichtet verhindert.

Man kommt also nicht umhin, neben seiner Applikation gleich auch noch das DB-Modell mit anzupassen.

Insofern sind Identities für zukunftige Entwicklungen wohl durchaus normal, wenn man nicht bei der alten zeilenweisen Programmierung verbleiben will .

[andreaspr@aon.at]

... der Punkt ist doch nicht ob man einen Primary Key hat und ob der einen semantischen Inhalt hat, sondern ob man sich den von der Datenbank generieren lässt, um ihn anschließend erst mal zu ermitteln, weil man ihn als Foreign Key für andere zu schreibende Tabellen benötigt - da steht doch jede Logik Kopf.

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.

[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