Aktualitätsprüfung TEMP-Datei

[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.