RRN trotz RGZPFM merken

[Fuerchau]

Dann wirst du auch mit Datei C nicht weiterkommen oder soll dieser Bezug manuell hergestellt werden?
Dann frage dich zuerst, welche der vielen Dateien ggf. als Primärdatei verwendet werden kann.
Dann erstelle Datei C mit den Primärschlüsseln (immer schön einzelne Felder) und ergänze dann die zusätzlichen Felder aus den anderen Dateien.
Über die Primärdatei kopierst du schon mal die Primärschlüssel, dann benötigst du nur noch ein Erfassungsprogramm, mit dessen Hilfe ein Begabter die Schlüssel aus den anderen Dateien dazu dichtet.

Tut mir leid, wenn das etwas gehässig klingt, aber programmtechnisch gibt es da keine Lösung.

[dholtmann]

Das sind einfach zu viele Schlüssel.
Dankeschön für deine Vorschläge und Zeit!
Ich denke, wir müssen da noch mal überlegen.

[Pikachu]

Also eine Datei, die alle Datensätze aller Dateien enthält und in der jeder Datensatz weiß, wo er herkommt?

[Fuerchau]

Dann sollte man sich doch noch mal überlegen, was denn mit dieser Datei C tatsächlich erreicht werden soll und wieso man Beziehungen erzwingen will, die gar nicht vorhanden sind.
Letztlich kann ich auch eine verwandschaftliche Beziehung mit dir herstellen, wenn ich bis in die Zeit der Auswanderung des Cro-Magnon aus Afrika zurückgehe.
Aber ob du das willst?

[dholtmann]

@Pikachu So in etwa, Sie enthält andere Daten die in keiner Datei vorhanden sind, aber dennoch satzspezifisch.

@Fuerchau In diesem Fall gibt es gar keine Verbindung. Nur den Fall, dass zu jedem Satz etwas gespeichert werden soll. Als hätte man die Tabellen Autos, Häuser, Wasserflaschen und wolle zu jedem den Besitzer und alle vorhergehenden Besitzer festhalten.

[BenderD]

@Pikachu So in etwa, Sie enthält andere Daten die in keiner Datei vorhanden sind, aber dennoch satzspezifisch.

@Fuerchau In diesem Fall gibt es gar keine Verbindung. Nur den Fall, dass zu jedem Satz etwas gespeichert werden soll. Als hätte man die Tabellen Autos, Häuser, Wasserflaschen und wolle zu jedem den Besitzer und alle vorhergehenden Besitzer festhalten.

... dann gehören diese Dateien um entsprechende Felder erweitert, wenn sie nicht zu externen Anwendungen gehören. Macht man das richtig (View Layer heißt das Zauberwort) ist das sehr einfach! Bei Fremdanwendungen bleibt (leider) nur noch pro Datei eine Erweiterungsdatei anzulegen, die den Schlüssel der verbundenen Datei plus die benötigten Erweiterungen enthält.

D*B

[dschroeder]

Ich gebe auch nochmal meinen Senf dazu: Wenn ich dich richtig verstehe, willst du Zusatzinformationen zu beliebigen Dateien speichern können. Dein Problem ist aber, dass die Dateien keine "genormten" Schlüsselfelder haben?
Wenn das so ist, wäre es doch eine Möglichkeit, die Zusatzinformationsdatei aus 4 Feldern bestehen zu lassen:
1. Dateiname char(10)
2. Key für Datei char(60) oder eben so lang, wie die längste eindeutige Key-Information ist
3. Art der Zusatzinfo char(20)
4. Zusatzinfo char(200)

Wenn deine Datei A z.B. Kunden enthält und der Schlüssel eine 10-stellige Kundennummer ist und du zusätzlich den Geburtstag der Oma des Kunden speichern willst, müsstest du in der Zusatzinfodatei folgendes speichern:
Dateiname = 'A';
Key = %char(kundennummer);
art = 'OMA_GEBURTSTAG';
zusatzinfo = '15.12.1927';

Wenn du die Tabellen später miteinander verknüpfen wills, muss du natürlich abhängig vom Dateinamen die Verknüfungszeichenfolge aufbauen.

Dieter

[Fuerchau]

Das sind dann irgendwann so Dateien, die mit SQL kaum bis gar nicht mehr auswertbar sind.
Hier muss ich Dieter recht geben, dass man zu jeder betroffenen Datei eine Zusatzdatei mit den Schlüsselfeldern sowie den benötigten Zusatzinformationen anlegt.
Eine Sammeldatei für alles mögliche oder auch unmögliche, macht es dann später ebenso unmöglich überhaupt noch etwas sinnvoll damit anzufangen.

Man muss auch mal an die Zukunft denken, wenn man Auswertungen, Web-Anwendungen o.ä. erstellen will und die Clientprogrammierer, die dann nur mit SQL an die Daten kommen, die Hände über den Kopf schlagen und solche Projekte dann an solchen Datenmodellen scheitern.

Treibe lieber jetzt den Aufwand, das Datenmodell entsprechend aufzubauen, das dann SQL-konform und zukunftsorientiert ist. Das Zeitalter der Satzarten-Verarbeitung ist doch weitestgehend mit der Einführung der Festplatte verschwunden.

[dschroeder]

Das sind dann irgendwann so Dateien, die mit SQL kaum bis gar nicht mehr auswertbar sind.
Hier muss ich Dieter recht geben, dass man zu jeder betroffenen Datei eine Zusatzdatei mit den Schlüsselfeldern sowie den benötigten Zusatzinformationen anlegt.
Eine Sammeldatei für alles mögliche oder auch unmögliche, macht es dann später ebenso unmöglich überhaupt noch etwas sinnvoll damit anzufangen.

Man muss auch mal an die Zukunft denken, wenn man Auswertungen, Web-Anwendungen o.ä. erstellen will und die Clientprogrammierer, die dann nur mit SQL an die Daten kommen, die Hände über den Kopf schlagen und solche Projekte dann an solchen Datenmodellen scheitern.

Treibe lieber jetzt den Aufwand, das Datenmodell entsprechend aufzubauen, das dann SQL-konform und zukunftsorientiert ist. Das Zeitalter der Satzarten-Verarbeitung ist doch weitestgehend mit der Einführung der Festplatte verschwunden.

Da bin ich voll bei dir. Wir haben auch ein paar von diesen Sammeldateien, die ich heute lieber nicht mehr hätte. Ich wollte nur sagen, dass so etwas auch geht, wenn man denn unbedingt mit einer Datei arbeiten möchte.

[Fuerchau]

In solchen Fällen (habe ich aus einem anderen Projekt) bieten sich doch hochflexible XML-Dateien an. Hier kann man beliebig tief schachteln und alles in in Tera-BLOB packen.
Viel Spaß dann beim ver- und bearbeiten.

Solche Konzepte gibt es z.T. wirklich!

[BenderD]

... mein Hauptproblem mit solchen divers (pervers) Dateien ist, dass die nicht mit den zugehörigen Daten in einem join dargestellt werden können.

D*B

[dholtmann]

Ich gebe auch nochmal meinen Senf dazu: Wenn ich dich richtig verstehe, willst du Zusatzinformationen zu beliebigen Dateien speichern können. Dein Problem ist aber, dass die Dateien keine "genormten" Schlüsselfelder haben?
Wenn das so ist, wäre es doch eine Möglichkeit, die Zusatzinformationsdatei aus 4 Feldern bestehen zu lassen:
1. Dateiname char(10)
2. Key für Datei char(60) oder eben so lang, wie die längste eindeutige Key-Information ist
3. Art der Zusatzinfo char(20)
4. Zusatzinfo char(200)

Wenn deine Datei A z.B. Kunden enthält und der Schlüssel eine 10-stellige Kundennummer ist und du zusätzlich den Geburtstag der Oma des Kunden speichern willst, müsstest du in der Zusatzinfodatei folgendes speichern:
Dateiname = 'A';
Key = %char(kundennummer);
art = 'OMA_GEBURTSTAG';
zusatzinfo = '15.12.1927';

Wenn du die Tabellen später miteinander verknüpfen wills, muss du natürlich abhängig vom Dateinamen die Verknüfungszeichenfolge aufbauen.

Dieter

Denke darauf wird es hinaus laufen.
Auslesen geht über Umweg QADBILFI & View mit Hilfe des Dateinamens ja auch.
Hatte halt gehofft über die RRN eine schönere Lösung zu erreichen.

Bei Fremdanwendungen bleibt (leider) nur noch pro Datei eine Erweiterungsdatei anzulegen, die den Schlüssel der verbundenen Datei plus die benötigten Erweiterungen enthält.

Das wäre der richtige Weg, aber bei wer weiß wie viel hundert Dateien kann ich das auch nicht machen.