LF, View, Index

[B.Hauser]

Such mal nach Identity Columns:https://www.ibm.com/docs/en/i/7.4?to...dentity-column
Solange Du über die Identity Column einen Primary Key Constraint (oder einen Unique Key) legst, und dem System keinen Cycle erlaubst und den Zähler nicht manuell zurücksetzst, wird die Identity Column beim Insert (aber auch beim RPG write) automatisch (ohne Trigger) generiert.

... und Identity columns können mal eben so eingeführt werden! Der Aufwand ist nicht größer als wenn in einer Datei ein neues Feld eingefügt oder ein vorhandenes Feld geändert wird.

[BenderD]

... und Identity columns können mal eben so eingeführt werden! Der Aufwand ist nicht größer als wenn in einer Datei ein neues Feld eingefügt oder ein vorhandenes Feld geändert wird.

... eigentlich ist er kleiner, wenn man das so einrichtet, dass am Ende der Aktion eine DDS-LF mit dem ursprünglichen Namen der PF, gleichen Feldern und gleicher Format-ID existiert.

D*B

PS: was macht ihr denn mit RPG RLA, was mit SQL nicht geht? Vielleicht macht ihr da ja was auf dem 2.-besten Weg!

[dibe]

Danke für diese Information!

So wie sich das liest muß die Datei aber SQL beschrieben sein.
oder geht ein

Alter Table add colum
ORDERNO SMALLINT NOT NULL
GENERATED ALWAYS AS IDENTITY
(START WITH 500
INCREMENT BY 1
CYCLE)

Wenn ich alles auf SQL basiere Dateien umstelle, bekomme ich das Satzformat Problem
(obwohl ... ich glaube das kann SQL auch mitlerweile!?)

Und was bedeutet ... dem System keinen Cycle erlaubst ...

Vielen Dank
Dietlinde Beck

[BenderD]

... man kann problemlos eine DDS LF auf eine SQL erstellte PF stellen, die dasselbe Format, wie die ersprüngliche PF hat.

[Fuerchau]

Was willst du mit einer Identity von max. 32767 Werten;-)?
Eine Identity dient i.d.R. auch als Primary Key und sollte daher mindestens Integer sein.

Mit Table Functions habe ich bisher keine schlechten Erfahrungen gemacht.
Die IBM baut ja selber dauernd neue für die ganzen Vewaltungs-API's (Service-Views).

Table-Functions und Procedures dienen ja nur zur Verbergung von direkten SQL-Zugriffen und stellen zumindest nach meiner Erfahrung kein Problem dar.

Was das Create Table angeht, so kann man natürlich einen Satzformatnamen angeben, in RPG/LE kann man den aber auch umbenennen.

Aber wie immer in der IBM i-Welt: es gibt 100te Meinungen und 1000de Lösungen;-).

[dibe]

Habe das gerade mal ein wenig probiert,
mit "alter Table" geht das auf DDS beschriebene PF, das ist gut.
Gelöschte Sätze werden mitgezählt, das ist schlecht.
ein RGZPFM nummeriert neu durch, das wäre eine Katastrophe, dann wären ja alle abh. Dateien falsch!
kann man das einstellen?

[B.Hauser]

Habe das gerade mal ein wenig probiert,
mit "alter Table" geht das auf DDS beschriebene PF, das ist gut.
Gelöschte Sätze werden mitgezählt, das ist schlecht.
ein RGZPFM nummeriert neu durch, das wäre eine Katastrophe, dann wären ja alle abh. Dateien falsch!
kann man das einstellen?

Lass das! Spätestens bei der nächsten DDS-Änderung hast Du die Identity vergessen!

Konvertiere die Tabelle nach DDL und füge dann die Spalte hinzu.
Erstelle das SQL Skript über Reverse Engineering (ACS Wizard - Generate SQL oder SQL Stored Procedure GENERATE_SQL), achte darauf, dass CREATE OR REPLACE TABLE angegeben ist.
Führe das SQL Skript aus ... und schon ist die Tabelle konvertiert! Wenn Du nur konvertierst und keine neuen Spalten einfügst brauchst Du noch nicht einmal die RPG-Programme mit Native I/O zu kompilieren.

Aber Achtung: Vor der Konvertierung musst Du sicherstellen, dass Deine physische Datei keine ungültigen numerischen Daten (z.B. *Blanks) enthält, ansonsten gehen Dir Daten verloren.
In der Bibliothek SYSTOOLS gibt es die Funktionen VALIDATE_DATA, VALIDATE_DATA_FILE und VALIDATE_DATA_LIBRARY mit denen Du auf ungültige numerische Werte prüfen kannst. Diese müssen zunächst korrigiert werden.

Alle Daten und abh. Objekte bleiben erhalten und müssen nicht neu erstellt werden.

[Andreas_Prouza]

Ein RGZPFM ändert nicht die Nummer bei einer Identiy Spalte.
ei Commit-Steuerung, wenn neu erstellte Sätze doch wieder mit Rollback entfernt werden, entstehen ebenfalls Lücken im Nummernkreis.
Das ist aber völlig egal und hat auch niemandem zu interessieren, da die Nummern nicht für eine hübsche Lesbarkeit sondern für Eindeutigkeit und Integrität bei Fremdschlüsseln dienen.

Ich verwende (meistens) sowieso nur noch BIGINT für die ID.
Teilweise haben wir hier noch ein Denkschema von 1980 wo jedes Byte gezählt hat.
Heute erzeugen wir durch dieses Denkschema nur langfristige Probleme, denn von der Performance merkst du da bei den Maschienen keinen Unterschied mehr.