Aktualitätsprüfung TEMP-Datei

[Pikachu]

Ob eine Aktualitätsprüfung erfolgen soll oder nicht, ist eine Eigenschaft der Datei, die man beim Erstellen der Datei (mittels CRTPF) angibt und die man nachträglich ändern (mittels CHGPF) oder überschreiben (mittels OVRDBF) kann.

[Fuerchau]

Ausserdem ist für die Aktualitätsprüfung die Quelle vollkommen unerheblich.

Beim compilieren wird die "Fmt.EbenenID" des verwendeten Satzformates in das Programm kopiert und beim Öffnen geprüft.
Bei Abweichung wird der Open eben abgelehnt.

Natürlich kann man per CHGPF den LVLCHK abschalten.
Werden Felder nur am Ende angehängt, gibts beim Lesen und Ändern keine Schwierigkeiten.
Das Hinzufügen wird dann abgelehnt, wenn die unbekannten Felder ungültige Daten enthalten, was bei Dezimalfeldern immer der Fall sein wird.

Bei SQL stellen sich diese Probleme gar nicht, da hier dieses Konzept unbekannt ist.
Der Open wird dann eben abgelehnt, wenn Felder verschwunden sind, neue Felder sind dem SQL egal.
Beim Insert müssen für die Tabelle nur gültige Defaultwerte definiert sein oder per Trigger korrekt gefüllt werden.

[Mr.iSeries]

Zitat:
Ob eine Aktualitätsprüfung erfolgen soll oder nicht, ist eine Eigenschaft der Datei, die man beim Erstellen der Datei (mittels CRTPF) angibt und die man nachträglich ändern (mittels CHGPF) oder überschreiben (mittels OVRDBF) kann.


Das ist mir schon klar... Die Frage war jedoch wie das bei Dateien abläuft die in der QTEMP vor PGM-Aufruf immer neu erstellt bzw. kompiliert werden... Dann ist das Objekt der PF eigentlich ja immer neuer als das des PGM's... Die Aktualitätsprüfung müsst ja trotzdem greifen oder? Wenn ich z.B. in die Source der PF ein neues Feld einfüge, jedoch die PF nicht erstelle und das PGM auch nicht neu kompiliere was ist dann? Ich dachte eben vor PGM-Aufruf wird die Quellendatei hergeholt und dann in die QTEMP kompiliert aber anscheinend holt er sich die Daten wo anders her.

[Pikachu]

Bei der Aktualitätsprüfung wird die Formatebene der Datei mit der im Programm eingebundenen Formatebene der Datei (zum Zeitpunkt der Programmerstellung) verglichen. Das Erstellungsdatum der Datei ist dabei egal.

[Fuerchau]

Quellen müssen ja zur Laufzeit nicht zur Verfügung stehen.

An Stelle per Quelle und CRT-Befehl ein Objekt ständig neu zu erstellen, würde ich eher CRTDUPOBJ empfehlen.

Ausserdem generiert sich die FMT-Id aus einer Checksumme, die von der Anzahl Felder, Typ und Ausprägung sowie Reihenfolge ergibt.

Solange man also in der Quelle ausser Kommentaren nichts ändert, ändert sich auch an der FMT-ID nichts.

Ein kleiner Fehler ist da allerdings schon dabei.
Der Key einer PF/LF unterliegt nicht der FMT-ID. Ändert man also den Key, fliegt einem das Programm leider erst beim Zugriff und nicht bereits beim Open um die Ohren.

[BenderD]

@Baldur: gilt nur für DDS erstellte Dateien!!!

Ausserdem generiert sich die FMT-Id aus einer Checksumme, die von der Anzahl Felder, Typ und Ausprägung sowie Reihenfolge ergibt.

[Fuerchau]

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.

[Pikachu]

Für SQL gibt's da wohl ein paar PTFs.

[BenderD]

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.

[Fuerchau]

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.

[BenderD]

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.

[BenderD]

aufs Erstellungsdatum kommt es nicht an, nur auf die Formatebenen ID und die leitet sich bei DDS aus der Struktur des Buffers ab (Folge: gleiche Quelle führt immer zur gleichen Format Ebenen ID, selbst unterschiedliche Dateien können dieselbe Formatebenen Id haben). Programme merken sich beim Compile die Format Ebenen ID der vorgefundenen Datei und solange die zur Laufzeit passt, stimmts.
Bei SQL erstellten Dateien ist das ein wenig anders, da wird der T e x t des SQL Statements in die Formatebenen Id verschlüsselt, was bei Rekord Löffel Ekzem dann zu Problemen führt.
SQL Verwendung in Programmen interessiert sich nicht für Format Ebenen Ids, da wird zur L a u f z e i t Feldweise geprüft, ob die Felder miteinander Typ verträglich sind und gegebenen Falls auch entsprechend gecastet und widrigenfalls nicht ausgeführt!!!

D*B

Zitat:
Ob eine Aktualitätsprüfung erfolgen soll oder nicht, ist eine Eigenschaft der Datei, die man beim Erstellen der Datei (mittels CRTPF) angibt und die man nachträglich ändern (mittels CHGPF) oder überschreiben (mittels OVRDBF) kann.


Das ist mir schon klar... Die Frage war jedoch wie das bei Dateien abläuft die in der QTEMP vor PGM-Aufruf immer neu erstellt bzw. kompiliert werden... Dann ist das Objekt der PF eigentlich ja immer neuer als das des PGM's... Die Aktualitätsprüfung müsst ja trotzdem greifen oder?