RRN trotz RGZPFM merken

[dholtmann]

Hallo zusammen,

ich überlege einen Satz anhand von Dateiname und RRN zu identifizieren.
Leider ist mir aufgefallen, dass RGZPFM keine Trigger auslöst.
Gibt es trotzdem eine Möglichkeit zu erkennen, wenn die RRN geändert wird?
Falls ja, könnte ich anhand der alten und neuen Nummer ein Update durchführen und diese Verlinkung erhalten. Vielen Dank schon mal.

[Fuerchau]

Nein, die gibt es nicht. Eine Verlinkung von Daten per RRN ist das fatalste was man machen sollte.
Da reicht es schon, wenn man die Daten hin- und herkopiert um Beziehungen zu verlieren.
Ich würde dir da auf jeden Fall ein Feld mit einer eindeutigen ID empfehlen.
Dies hilft auch z.B. bei Client-Programmen in .NET/Java u.ä.

Wenn du da nicht mehr rauskommst, empfehle ich dir REUSEDLT(*YES) einzustellen, dann sparst du auf jeden Fall den Reorg.
Übrigens wird eigentlich bei Trigger ein RGZPFM nicht erlaubt.

[dholtmann]

Dankeschön,
habs befürchtet.
hin- und herkopieren etc. hätte man ja noch über Trigger abfangen können.
Es geht halt darum, viele Dateien mit verschiedenen Keys zu verlinken.
Schön gewesen wäre deshalb einfach File und RRN zu verwenden.
Aber ich dachte mir schon, dass das ein Traum bleibt und ich die echten Keys aufnehmen muss.

Vielen Dank!

[BenderD]

... das mit der RRN ist wohl nur die zweitbeste Idee.

- REUSEDLT wäre fatal, da werden dann ja Beziehungen geerbt.
- obwohl ich ungern Beihilfe zur Beibehaltung von Huddel leiste: RGZPFM läuft ja meist exclusiv, da kann man sich vorher die alte RRN merken und dann bei den geänderten glatt ziehen.

Besser wäre es natürlich diesen Murks zu sanieren!!!

D*B

[dholtmann]

Noch gibt es das mit der RRN ja nicht.
Werde mich nach euren deutlichen Worten auch davor hüten .
Möchte halt letztendlich Folgendes abbilden:
Datei A hat die Keys Firma, Auftrag, Position.
Datei B hat die Keys User, Alter.
Datei C soll jetzt Verlinkungen zu beiden enthalten.

Bleibt mir jetzt bloß die Keys von A zu verketten und in C zu speichern und die B verketteten Keys in C zu speichern? (Jeweils mit Dateiname).

[Fuerchau]

Nein, ebenso nicht empfehlenswert.
Wenn du einen Schlüssel mit mehreren Feldern hast dann must du die Redundanz aller Felder über beide Dateien zu machen.
Vorteile:
- Verknüpfungen mit SQL sind leichter möglich
- bei qualifizierten Strukturen kannst du die Felder auch identisch benamen
Der Dateiname gehört überhaupt nicht in die Felder, das ist unnötige Redundanz und kann bei irgendwelchen Zugriffen auch gar nicht verwendet werden.
Einfach sind sog. Identity-Spalten, als einfach ein Feld mit einer Laufenden-Nr. die man eindeutig ermittelt und dann jeweils in der korrespondierenden Datei speichert.
Die Datei C ist vollkommen unnötig.

[dholtmann]

Nein da hab ich mich vllt falsch ausgedrückt.
Es geht mir um Datei C. Die soll halt bestimmte Informationen aus A und B enthalten.

[Fuerchau]

M.a.W: Datei A und B sind bereits vorhanden?
Dann hast du sicherlich Recht, wenn du eine neue Datei C erstellst.
Andererseits müsstest du dann ja bereits Beziehungen zwischen A und B herstellen können, so dass Datei C wieder hinfällig wird.
Bist du noch am Anfang, also beim Design der Dateien A und B, solltest du den Anssatz mit Datei C vergessen und die Schlüssel aus A ebenso in B führen.
Umgedreht benötigst du da keine Verweise, da die Verweise A auf B auch umgedreht funktionieren.

[BenderD]

Noch gibt es das mit der RRN ja nicht.
Werde mich nach euren deutlichen Worten auch davor hüten .
Möchte halt letztendlich Folgendes abbilden:
Datei A hat die Keys Firma, Auftrag, Position.
Datei B hat die Keys User, Alter.
Datei C soll jetzt Verlinkungen zu beiden enthalten.

Bleibt mir jetzt bloß die Keys von A zu verketten und in C zu speichern und die B verketteten Keys in C zu speichern? (Jeweils mit Dateiname).

... verketten macht man grundsätzlich nicht. Was ich noch nicht verstehe ist, was due da erreichen willst, willst du da eine Beziehung von Datei A zu Datei B abbilden?,

D*B

[dholtmann]

Datei A und B sind schon vorhanden. Es geht auch um wesentlich mehr als diese beiden Dateien.
Datei C soll Satzbezogen Infos pro Datei enthalten.

Sprich Datei A und B brauchen keine Beziehung untereinander. Ich brauche nur
A <-> C
B <-> C
...
N <-> C.
Finde das mit dem Verketten auch nicht toll, komme aber auf keine bessere Idee.

[Fuerchau]

Dann ist die Aufgabenstellung mir noch nicht klar.
Wenn du eine Beziehung A zu C und B zu C aufbauen willst, musst du doch bereits eine Beziehung A zu B herstellen können.
In diesem Fall reicht einfach eine View per SQL die die beiden Tabellen verbindet.
Ebenso ist mit den weiteren Tabellen zu verfahren.
Mit Verketten hat das ja nichts zu tun.

[dholtmann]

Genau das ist mein Problem. Zwischen A, B und den Restlichen gibt es keinen Bezug.