Probleme mit Identity Column in Table

[B.Hauser]

So wie Du die Identity definiert hast bezieht sich der MaxValue NICHT auf ADNR, sondern auf die ID.

Schau Dir die Spalten-Definition doch mal über die Catalog-View SYSCOLUMNS an.

Die nächste Identity-Nr kannst Du aus der Catalog-View SYSPARTITIONSTAT (Spalte NEXT_IDENTITY_VALUE) ermitteln.

Birgitta

[Tonazzo]

@B.Hauser
Genau das habe ich ja um 10:01 an @camouflage geschrieben (Thema ADRNR)!
Wo finde ich den Catalog-View SYSPARTITIONSTAT? Wir haben V5R4 auf der Maschine?

@andreaspr@aon.at
Eine Zurücksetzung/Änderung mit dem OPSERV ist schon möglich!

[Fuerchau]

Bei V5R4 wird es keine Fehlerbehebung mehr geben, da nützt ein IBM-Call auch nichts mehr.
Da ist halt raten angesagt.
"Generate Always" bedeutet nur beim Insert, dass ein Wert vergeben wird, egal ob ich NULL angebe, das Feld nicht verwende oder eine bestimmten Wert eintrage. Wäre ja fatal, wenn ein Update den Wert ständig verändern würde.
Dies verhindert nicht den (versehentlichen) Update des Wertes.

Auch könnte das Zurücksetzen des Wertes zu doppelten Sätzen führen. Eine Überlauf bei 2^31 Werten halte ich eher für unwarscheinlich.

[andreaspr@aon.at]

"Generate Always" bedeutet nur beim Insert, dass ein Wert vergeben wird, egal ob ich NULL angebe, das Feld nicht verwende oder eine bestimmten Wert eintrage. Wäre ja fatal, wenn ein Update den Wert ständig verändern würde.
Dies verhindert nicht den (versehentlichen) Update des Wertes.

Hast du das denn schon mal probiert?? Ich Tippe mal auf nein.

Hier auch noch zusätzlich ein Auszug aus dem Handbuch:

ALWAYS
Specifies that the database manager will always generate a value for the column when a row is inserted or updated and a default value must be generated.

[Fuerchau]

or updated = nur dann, wenn das Feld nicht schon einen Inhalt hat.
Wenn der Wert jedes mal erneuert würde, könnte ich diesen nicht als Schlüsselverweis in einer anderen Tabelle verwenden, dann wäre er sinnlos.

[B.Hauser]

Bei einem so alten Release, wirst Du auch keine Unterstützung von der IBM mehr bekommen.
Ob es die View SYSPARTITIONSTAT schon in Release V5R4 gab, weiß ich nicht aus dem Stehgreif.
Ansonsten findest Du die View in der Bibliothek QSYS2.

... ich finde es immer erstaunlich, dass Firmen auf der i mit Release-Ständen arbeiten, die über 10 Jahre alt und bereits seit 3 Jahren abgekündigt sind. Das aktuelle Release 7.2 (zwischen V5R4 und 7.2 sind noch die Releases 6.1 und 7.1), ist inzwischen auch schon wieder 2 Jahre alt und es wird spekuliert, ob im Mai das nächste Release angekündigt wird.

... auf der anderen Seite werden oft bei den gleichen Firmen im PC-Bereich keine Kosten gescheut, um immer auf dem neuesten Stand zu sein.

[Fuerchau]

Vielleicht liegt das ganz einfach an der Lizenzpolitik sowie den Preisen für neue Hardware.
Im Gegensatz zu Windows läuft die AS/400 eben sehr stabil.
Warum soll ich ein OS-Update durchführen wenn ich gleichzeitig auch noch die Hardware austauschen muss?
Warum soll ich teurere Compiler bezahlen nur weil die IBM die OPM-Compiler abschaffen will bzw. sich nun teuer bezahlen lässt?
Warum soll ich auf das teure und größere und schnellere Hardware voraussetzende Web/Query umsteigen wenn mir das Query/400 ausreicht und ich ansonsten PC-Lösungen einsetze?
Manchmal verhindert auch meine ERP-Anwendung den Umstieg weil ich vielleicht keine Quellen habe und das Softwarehaus nicht mehr existiert und es auch keinen AS/400-Softwarenachfolger gibt.
Es gibt viele Gründe den Status Quo beizubehalten. Im Mittelstand sind es hier tatsächlich die Kosten und den vermissten tatsächlichen Mehrnutzen für meine existierenden Anwendungen.

Und dann gibt es noch solche wie mich, die diesen Anwendern auch noch helfen, mit diesem Status Quo noch weiter zu kommen.

[B.Hauser]

Vielleicht liegt das ganz einfach an der Lizenzpolitik sowie den Preisen für neue Hardware.
Im Gegensatz zu Windows läuft die AS/400 eben sehr stabil.
Warum soll ich ein OS-Update durchführen wenn ich gleichzeitig auch noch die Hardware austauschen muss?
Warum soll ich teurere Compiler bezahlen nur weil die IBM die OPM-Compiler abschaffen will bzw. sich nun teuer bezahlen lässt?
Warum soll ich auf das teure und größere und schnellere Hardware voraussetzende Web/Query umsteigen wenn mir das Query/400 ausreicht und ich ansonsten PC-Lösungen einsetze?
Manchmal verhindert auch meine ERP-Anwendung den Umstieg weil ich vielleicht keine Quellen habe und das Softwarehaus nicht mehr existiert und es auch keinen AS/400-Softwarenachfolger gibt.
Es gibt viele Gründe den Status Quo beizubehalten. Im Mittelstand sind es hier tatsächlich die Kosten und den vermissten tatsächlichen Mehrnutzen für meine existierenden Anwendungen.

Und dann gibt es noch solche wie mich, die diesen Anwendern auch noch helfen, mit diesem Status Quo noch weiter zu kommen.

... und im Endeffekt fliegt das "veraltete" System mitsamt den "veralteten" Anwendungen raus, weil in der PC welt alles viel "besser" und "moderner" ist.

[Tonazzo]

Also Leute,

da der komplette Zugriff auf diese Datei über eine Serviceporgramm läuft und in der Prozedur
für Update dieses Feld (SET ID) nicht geändert wird, wird die ID auch dort nicht umgebogen.

Ich kann dieses Feld allerdings im OPNAV verändert. (Definition auf Feldebene).

@B.Hauser
Wie H. Fuerchau schon geschrieben hat: Es gibt viele Gründe den Status Quo beizubehalten.
Keine Angst wir bleiben bei der AS/400/iSeries/System I/I5 etc.... ;-)

Um mir die nächste ID anzusehen sollte folgender Befehl passen:
select NEXT_IDENTITY_VALUE from SYSPSTAT
where TABSCHEMA = 'MYLIB' AND TABNAME = 'ADRESSP'

[Fuerchau]

@Birgitta
Da kann man dem Anwender aber keinen Vorwurf draus machen.
Die wenigsten pflegen und entwickeln ihre Anwendung selber.
Man verlässt sich da halt auf die Software-Häuser.
Wenn die leider nicht mitspielen und ihre Anwendungen für die AS/400 weiterentwickeln bleibt dem Anwender nichts übrig als die "alte" AS/400 rauszuschmeißen und die "neue PC-Welt" reinzuholen.
Viele trauern ihrer AS/400 dann auch nach, aber es gibt halt kaum noch neue oder modernisierte ERP-Anwendungen für die AS/400.
Die Anwender, die auf die neuen OS-Versionen wechseln haben halt
- die Software in Eigenverantwortung
- noch real lebende Softwarehäuser
- mögen kein SAP

[B.Hauser]

Ich sehe das leider umgekehrt.
Ich arbeite in einem Softwarehouse und wir dürfen/können erst nachden der letzte Kunde sich bewegt hat selber umstellen (zumindest was die Software angeht).
Allerdings auch nur wieder an das niederste Release eines Kunden.

Wo beißt sich den da die Katze in den Schwanz??? Die "Anwender" können nicht upgraden weil die "Softwareh-Häuser" nicht upgraden und die Software-Häuser können nicht upgraden, weil irgend ein Kunde noch einen alten Stand hat.

Was glaubt Ihr wie oft ich schon geflucht habe, weil ich Räder neu erfinden musste, die in den höheren Release bereits erfunden waren.

Birgitta

[TheDevil]

Und was die "Mickey Mouse" Fraktion angeht ... auch hier kommt mit neuen Release von irgendwelcher
Software dann die Frage nach dem SQL Server (was ihr habt noch 2005 = geht nicht). Und auch
Softwarefirmen von Win Soft machen mal dicht und dann steht man im Regen.

Also eigentlich gibt es hier keine gravierenden Unterschiede zwischen der i5 und Win Fraktion. Gab auch schon Firmen die von Win Software auf i5 Software umgestiegen sind (Kosten Nutzen ...)

Gruß,
Ralf