View Full Version : Aktualitätsprüfung TEMP-Datei
Auch bei TABLE's habe ich eine FMT-Id, die nach gleichen Kriterien erstellt und bei Native-Open auch geprüft wird.
Natürlich kann ich den LVLCHK auch dort abschalten.
PS:
Übrigens nicht zu verwechseln mit der "Dateiebenen-ID", die nur einen Timestamp in der Form CYYMMDDHHMMSS darstellt und nur informatorischen Wert darstellt.
Für SQL gibt's da wohl ein paar PTFs (http://www-912.ibm.com/n_dir/nas4apar.NSF/1be1a5b61b213a6c86256c23007048f4/21529fcce2f4b070862571010041fe11?OpenDocument).
dann mach doch mal ein
create table hugo like myTable
und auch mal ein
create table qtemp.otto as (select * from mytable) with no data
oder ändere mal ein SQL Skript ab (sagne wir mal ein Feldname
und vielleicht auch mal ein
create view ddd as select * from mytable
und dann bin ich mal gespannt, ob du das bekommst, was du erwartest?!
Dieter Bender,
der das auch mal geglaubt hat (obwohl sein Urgroßvater bereits aus der Kirche ausgetreten ist)
Ob das ein Bug, oder ein Feature ist und ob das nur zuschlägt wenn man die SQL Möglichkeiten wirklich nutzt, das weiß ich nicht, aber seitdem mir das mal zufällig (stört nicht, weil ich durchgängig mit SQL arbeite) aufgefallen ist, ist das durchgängig so (mit mehr als 10 Group PTF Ständen unter mehreren Releases)
Auch bei TABLE's habe ich eine FMT-Id, die nach gleichen Kriterien erstellt und bei Native-Open auch geprüft wird.
Natürlich kann ich den LVLCHK auch dort abschalten.
PS:
Übrigens nicht zu verwechseln mit der "Dateiebenen-ID", die nur einen Timestamp in der Form CYYMMDDHHMMSS darstellt und nur informatorischen Wert darstellt.
Ich streite ja nicht ab, dass die Berechnung der ID anders läuft.
Aber wenn Quelle und Ziel identisch bleiben, bleibt auch die ID identisch.
Ändere ich z.B. den Zielnamen, gibts (hier im Gegensatz zu DDS) auch tatsächlich eine neue ID.
Ich nehme mal an, dass SQL einfach sicherstellen will, dass die ID für das gewünschte Objekt eindeutig sein soll und nicht nur bezogen auf den Satzpuffer.
Dies hebt insbesonders den Nachteil auf, dass bei DDS-Schlüsseländerung die ID bleibt, wobei bei CREATE INDEX mit einem anderen Schlüssel auch die ID eben eine andere ist.
Ich gebe dir allerdings insoweit Recht, dass man Table-Objekte auch nur mit SQL bearbeiten sollte.
die Berechnung der Fromagebenen IDs in SQL ist alles ein einziger Sch... (in Worten: Sch...) nur ein paar Highlights:
Änderung eines Feldnamens (ohne sonstige Änderung) ändert die Formatebenen ID
Änderung eines Feldes im Typ ändert die Formatebenen Id einer darauf hockenden View nicht unbedingt!!!
Duplizieren einer Datei mit create table like ändert die Formatebenen Id.
Mit Schlüsseln hat das alles nix zu tun, die leigen bei SQL ohnehin völlig außerhalb dieser Logik (Constraints).
Mein Resumee (nicht nur aus diesen Gründen):
Mix aus DDS/RLA und SQL ist was für Leute, die noch Probleme suchen. Entweder reinrassig DDS/RLA oder alles mit SQL.
Ich streite ja nicht ab, dass die Berechnung der ID anders läuft.
Aber wenn Quelle und Ziel identisch bleiben, bleibt auch die ID identisch.
Ändere ich z.B. den Zielnamen, gibts (hier im Gegensatz zu DDS) auch tatsächlich eine neue ID.
Ich nehme mal an, dass SQL einfach sicherstellen will, dass die ID für das gewünschte Objekt eindeutig sein soll und nicht nur bezogen auf den Satzpuffer.
Dies hebt insbesonders den Nachteil auf, dass bei DDS-Schlüsseländerung die ID bleibt, wobei bei CREATE INDEX mit einem anderen Schlüssel auch die ID eben eine andere ist.
Ich gebe dir allerdings insoweit Recht, dass man Table-Objekte auch nur mit SQL bearbeiten sollte.