View Full Version : SQL - CREATE TABLE automatisher Satzzähler
Wie gesagt, ich habe eine Fehlermeldung bekommen wenn ich beim Insert die Spalte verwende.
Mehr behaupte ich ja gar nicht.
Ergänzend zu Birgitta sei noch folgendes hinzugefügt:
Wie auch von Dieter schon des öfteren erwähnt, verwende ich natürlich kein native IO, wenn ich eine Tabelle mit SQL erstelle. Somit erklärt sich die Diskrepanz zwischen Birgitta und mir:
Wenn ich die Tabelle mit ILERPG beschreibe, kann ich in das ID-Feld reinschreiben was ich will, es wird immer ein Satz mit der nächsten Nummer erstellt.
Also muss der Compiler an Hand der Tabelleninformationen ggf. das Id-Feld ausschließen oder SQL prüft bereits vor dem Write die Zulässigkeit der Verwendung dieses Feldes.
Sowas schließ dann z.B. einen einfachen Insert aus einer Struktur aus, ich muss grundsätzlich mit einer View ohne ID-Feld arbeiten auch wenn ich dann in die tatsächliche Tabelle einfüge (nur wegen der Tipparbeit).
Nun komme ich aber in meinen Augen zu einem fatalen Fehler:
Birgitta erwähnte den CPYF mit FMTOPT(*MAP *DROP).
Auf diese Verwendung wäre ich gar nicht gekommen, da diese ja eigentlich nur bei abweichende Definitionen erforderlich ist.
Also habe ich dies ausprobiert und ich muss zugeben, es funktioniert.
Allerdings mit einer fatalen Auswirkung:
Die Datensätze aus der Quelle werden mit der ID der Quelle übertragen, es wird also keine ID aus dem Ziel neu vergeben.
Habe ich keinen Unique-Key definert (weil ich dachte, ALWAYS wäre ausreichend) erhalte ich nun Doppelte ID's. Mit einem Unique-Key kann ich die Daten aber nicht kopieren.
D.h., der CPYF kopiert auf einer tieferen Ebene die Daten als der Zugriff per RPG, da ja hier eine Nummer grundsätzlich vergeben wird.
Erst wenn ich mir tatsächlich eine View ohne das ID-Feld anlege und dann aus dieser View als Quelle ins Ziel mit *MAP/*DROP kopiere erhalte ich auch tatsächlich neue ID's.
Also ist trotz der Definition der ID als GENERATE ALWAYS nicht sichergestellt, dass es keine doppelten ID's gibt.
Von der Manipulation der ID mit Reset würde ich sowieso abraten.
Bei einer 32-Bit Ganzzahl bekomme ich bei ca. 58000 Sätzen täglich ca. 100 Jahre weit.
Bei einer 64-Bit Ganzzhal habe ich eine Reserve für die nächsten 100 Jahre von ca. 252 Billionen Sätze pro Tag. Da platzt ja eher die AS/400 als dass es einen Grund zum Rücksetzen der ID gibt. Auch nicht bei einem CLRPFM, denn wer weiß wo die ID schon in irgendeiner Form weitergegeben ist.
Nachtrag:
CREATE TABLE NEWTABLE LIKE IDENTTABLE
erzeugt keine Identity-Spalten!
Ein CRTDUPOBJ macht dies aber doch, da dieser auf SAVRST-basiert (schon bevor es die SAVRST-Befehle gab).
Interessant wäre noch die Verwendung einer solchen Tabelle in einem Java/.NET-Framework.
Ich komme nicht dazu dieses auszuprobieren und ob die Identity-Spalte beim Insert rausfliegt oder mittels DEFAULT belegt wird.
Wobei ich mich frage wozu das Schlüsselwort DEFAULT wirklich gut ist:
1. ich kann es nur als SQL-Text und nicht als Parametermarker verwenden (ist ja klar)
2. DEFAULT heißt ja, nimm den den hinterlegten DEFAULT-Value der Spalte
ergo, lasse ich die Spalte weg, wird ebenso der DEFAULT-Value verwendet, was in meinen Augen viel logischer ist.
Übrigens ist DEFAULT wiederum nicht erlaubt wenn die Spalte keinen Default hat, was es ja auch geben soll. NULL kann kein Default sein, denn Default ist von NULL verschieden. Lasse ich eine NULL-Spalte ohne Default weg erhält sie automatisch den NULL-Wert, wobei ich aber einen NULL-Wert explizit angeben kann, den DEFAULT aber nicht.
Oder gibts da wieder was für RPG'ler?
In ODBC/JDBC/.NET gibt es Entsprechungen wie NULL, null, DBNull.Value, ...
Und wie mache ich das in RPG?
Hier zieht grundsätzlich kein DEFAULT, da im Datenpuffer eben alles mit Blank oder Zero initialisiert wird. Wenn ich also einen Default '00' auf einem CHAR-Feld definiere, kann ich das durch unterlassen in SQL bekommen. In RPG muss ich as trotzdem selber machen.
Jetzt kommt Birgitta bestimmt mit der View.
Aber das ist doch selbstverständliche, dass für die nicht erwähnten Felder NULL/Default gilt, für die Felder der View jedoch kein DEFAULT.
Mittels %nullind(Feld) kann ich zumindest auf die NULL-Flags einfluss nehmen.
Was mich immer noch darüber rätseln lässt wozu der Schlüsselwert DEFAULT taugt.
Obwohl, beim Update könnte man den Inhalt zurücksetzen:
update File set field = default ...
Wobei: hat das wirklich schon mal jemand gebraucht oder ist das jemanden schon mal untergekommen?
Schluss mit der Polemik.
Da liebe ich doch eher Dieters Satzzähler-Variante die man schon seit /36 so programmiert hat und totsicher ist.
Schluss mit der Polemik.
... schade, ich hatte doch so gehofft, dass noch ein flacher Kommentar kommt!
Da liebe ich doch eher Dieters Satzzähler-Variante die man schon seit /36 so programmiert hat und totsicher ist.
... naja, ich habe die doch ein wenig über /36 Niveau gehoben.
D*B
@Dieter
Die Parallelität der Entwicklungen ist immer wieder zu erkennen. Deine Lösung habe ich schon so zu meinen Nixdorf Computer-Zeiten in den frühen 80ern verwendet und von meinem Ausbilder gelernt. Da kannten wir uns noch gar nicht und IBM kannte ich nur als Schreibmaschine und Lochkarten-Stanzer.
Aber wie wir nun beide wissen, sobald die IBM eine generelle Lösung in die DB integriert versucht sie das Rad neu zu erfinden und kommt somit nur auf die zweitbeste Lösung und vergisst dann auch noch dazugehörende Randthemen.