keine doppelten Schlüssel in LF

[muadeep]

Hi *all

Ist es möglich eine logische Datei zu erstellen, welche keine doppelten Schlüssel
enthält?

Die physiche Datei enthält doppelte Schlüssel
Die logische Datei soll mir aber nur jeweils
den ersten Satz (und nicht alle Sätze mit gleichem Schlüssel) anzeigen

[RobertMack]

Hallo muadeep,

ich würde das mit einem SETGT nach jedem READ lösen,

Gruß Robert

[froehlich]

Hallo,

programmtechnisch könnte man dies ja
auch mit einer Gruppenwechsellogig
erledigen.
In beiden Fällen würde man sich ja
die logische ersparen.

Gruss Thomas

[muadeep]

ups, sorry

ich habe ganz vergessen, daß ich daß ja
schon in der DDS-Beschreibung der logischen
Datei bräuchte!

[Fuerchau]

Wenn die PF bereits doppelte Schlüssel enthält, ist es auch einer LF nicht mehr möglich, nur noch eindeutige Schlüssel zu verwalten.
Du kannst dies wirklich nur noch programmtechnisch lösen.

Anmerkung: Solltest du REUSEDLT(*YES) verwenden, ist nicht eindeutig gesichert, dass der 1. Satz in Keyfolge auch der zuerst erstellte Satz ist.

Übrigens: LF's lassen sich auch per SQL erstellen, siehe CREATE VIEW xxx for SELECT ....
Mittels "Group by" lassen sich dann auch eindeutige Schlüssel erstellen.
Diese LF läßt sich von RPG auch genauso verwenden. Wenn du diese dann liest und mittels gelesenem Schlüssel auf die PF per CHAIN zugreifst, erhältst du genau 1 Satz.

[BenderD]

Hallo,

das mit den SQL Views und Record Löffel Exzess, das ist so eine Sache: die haben keine Sortierung, die Reihenfolge der Sätze überlässt man dann dem Datenbanksystem und das kann sich da auch unter einem Folgerelease anders entscheiden, was nicht unwahrscheinlich ist.
Ansonsten sorgt natürlich Group By und distinct dafür dass die Views dann read only sind; wobei distinct garnicht geht, da ja nur die Schlüssel gleich sind und bei group by muss man dann auch noch Spaltenfunktionen verwenden, damit man alle Felder mit reinbekommt.
Fazit: mit DDS und mit record Löffel Exzess stößt man hier an Grenzen, da bleibt nur die Programm technische Lösung; SETGT oder alle lesen mit Gruppenwechsel Logik gibt sich hierbei nicht viel - für einen Satz könnte der SETGT schneller sein, für alle eher der Gruppenwechsel, beidesmal sind die Unterschiede in der Nähe der Messbarkeit.

mfg

Dieter Bender

PS: Was ich nicht verstehe ist, warum man sich so einen Unfug antut (wobei das auch ein Softwarelieferant gewesen sein kann, der solchen Murks auch noch verkauft hat, Kompliment an die Marketing Abteilung!)

Wenn die PF bereits doppelte Schlüssel enthält, ist es auch einer LF nicht mehr möglich, nur noch eindeutige Schlüssel zu verwalten.
Du kannst dies wirklich nur noch programmtechnisch lösen.

Anmerkung: Solltest du REUSEDLT(*YES) verwenden, ist nicht eindeutig gesichert, dass der 1. Satz in Keyfolge auch der zuerst erstellte Satz ist.

Übrigens: LF's lassen sich auch per SQL erstellen, siehe CREATE VIEW xxx for SELECT ....
Mittels "Group by" lassen sich dann auch eindeutige Schlüssel erstellen.
Diese LF läßt sich von RPG auch genauso verwenden. Wenn du diese dann liest und mittels gelesenem Schlüssel auf die PF per CHAIN zugreifst, erhältst du genau 1 Satz.

[B.Hauser]

Eine Alternative wäre eine View mittels SQL zu erstellen.
z.B.:
CREATE VIEW MyLib/MyView
AS SELECT DISTINCT Field1, Field2, ... FieldN
FROM MyFile

(entspricht SETGT + READ)

oder

CREATE VIEW MyLib/MyView
AS SELECT Field1, Field2, ... FieldN
FROM MyFile
GROUP BY Field1, Field2, ... FieldN

entspricht Gruppen-Wechsel-Logik

SQL-Views können in SQL-Abfragen verwendet werden und damit ganz einfach z.B. mittels Embedded SQL in RPG verarbeitet werden.

Zu den programmtechnischen Anmerkungen ist folgendes zu sagen:
Die Variante mit SETGT READ ist wesentlich sinnvoller als eine Gruppenwechsel-Steuerung.
Im ersten Fall wird jeweils nur der 1.Satz des Schlüssels gelesen.
Im zweiten Fall werden alle Sätze gelesen und nur beim Gruppenwechsel erfolgt eine Aktion.

Birgitta

[Unregistriert]

Interessant wäre allerdings die DDS Entsprechung für

CREATE VIEW MyLib/MyView
AS SELECT DISTINCT Field1, Field2, ... FieldN from table1 t1, table t2 where t1.fieldx=t2.fieldx and t1.fieldy='xx'

Dies ginge nämlich dann mit JOIN und COMP. Jedoch weiß ich nicht, wie man das distinct in DDS angeben kann.