DDS Select / Omit

[KingofKning]

Irgendwie stehe ich auf dem Schlauch.Ich möchte nur bestimmte Sätze in der LF haben.
A*____ K TETENR
A*____ S TESTS COMP(EQ 0)
A*____ TEFA COMP(EQ 1)
A* ____ TEST01 COMP(GE 20)
A* ____ TEST01 COMP(LE 699)
A* ____ S TEST11 COMP(EQ 50)
A*____ TEST11 COMP(EQ 53)
A*____ TEST11 COMP(EQ 58)
A*____ TEST11 COMP(EQ 100)
A*____ TEST11 COMP(EQ 101)

Ich bekomme hier aber auch Sätze mit Test11 = 120. Wo ist denn mein Denkfehler?

GG

[TheDevil]

Auf den ersten schnellen Blick würde ich sagen das der erste Select diese Sätze enthällt.
Gruß,
Ralf

[Robi]

das entspricht nunmal einem
... where tests=0 and tefa=1 and test01 between 20 and 699 or
test11 = 50 and test11=53 and test11=58 and test11=100 and test11=101

also werden deine test11 = 120 Sätze die 1. Bedingung erfüllen

[hgdieterle]

Hallo
wenn ich das übersetzte bedeutet dies:

(tests = 0 und tefa = 1 und test01 >= 20 und test01 <= 699) oder
(test11 = 50 und test11 = 53 und test11 = 58 und test11 = 100 und test11 = 101)

Die zweite Zeile dürfte niemal zutreffen, da test11 =50 und test11 =53 gleichzeoting nicht sein kann.

Ein satz mit tests = 0 tefa =1 test01 21 und test11 = 120 würde in der logischen Datei erscheinen.
Da die erste Zeile zutrifft

[Fuerchau]

Das Problem ist tatsächlich, dass du in DDS die Bedingung nicht schachteln kannst.
Die 2. Bedingung wird, wie schon gesagt nie zutreffen.
Für die 2. Bedingung, wenn da die anderen Felder nicht benötigt werden, musst du jedes mal wieder mit dem "S" für "or" beginnen.

Für deine 120 muss aber auch "tests=0 and tefa=1" gelten.

[ExAzubi]

Stelle vor den anderen TEST11 auch noch das 'S' für SELECT dann sollte es gehen...
Ansonsten ist ein CREATE VIEW auch eine gern genomnene Sache...

[B.Hauser]

Views haben keinen Schlüssel, deshalb sind sie für native I/O nur eingeschränkt einsetzbar.

Wenn KingOfKing auf Release 6.1 oder höher wäre, würde ich einen (derived and sparsed) SQL-Index vorschlagen.
Bei diesen Indices können Spalten ausgewählt, neue Spalten generiert werden (u.a. auch unter Verwendung von skalaren funktionen).
Daneben können WHERE-Bedingungen (das Äquivalent zu SELECT/OMIT-Anweisungen nur mächtiger, da die SQL-Syntax verwendet wird und damit u.a. auch Klammern gesetzt werden können) hinzugefügt werden.

SQL Indices können zwar in SQL-Statements nicht angegeben werden, wohl aber mit native I/O wie jede beliebige geschlüsselte DDS-beschriebene logische Datei verwendet werden.

Birgitta

[KingofKning]

Tja, das mit dem S vor den anderen hatte ich schon probiert, führt aber zu der Fehlermeldung "Doppelte Schlüsselwerte".

Da ich die Datei in Cobol bearbeiten will, muß ich eine LF haben.

Ansonsten müßte ich den Zugriff auf SQL umstellen.
Habe mir zwar den interessanten Vortrag von Herrn Bender angehört, aber noch keine Zeit das umzusetzen.

Ich finde es aber erstaunlich das es nicht möglich ist im DDS zu sagen "Nur die Sätze auf die alle Bedingungen zu treffen zu selektieren".

Nun ja, muß ich halt in Cobol schauen wie ich es mache.

GG

[B.Hauser]

Ich finde es aber erstaunlich das es nicht möglich ist im DDS zu sagen "Nur die Sätze auf die alle Bedingungen zu treffen zu selektieren".

DDS ist eine veraltetete Technologie und wird schon seit mindestens 4 Releasen nicht mehr weiterentwickelt. Deshalb haben wir ja die ganzen Neuerungen in Release 6.1 für die SQL Indices erhalten. (Übrigens unter 6.1 war diese Erweiterung in erster Linie nur für native I/O erst mit 7.1 konnte dann die SQE diese Zugriffspfade teilweise verwenden!).

Birgitta

[BenderD]

Ansonsten müßte ich den Zugriff auf SQL umstellen.
...
Nun ja, muß ich halt in Cobol schauen wie ich es mache.

GG

... das mit dem SQL ist sicherllich die nachhaltigere Lösung.
Alternativ gibt es noch zwei Varianten:
- OPNQRYF
- alle lesen und filtern
@OPNQRYF: ist zwar weniger schön als SQL und ein wenig tricky, aber ich würde das logischen mit select ommit allemal vorziehen, insbesondere dann, wenn ich viele solcher Ungetüme kriege und im Mix mit SQL fahre.
Wenn die Selektivität unter 20 % (vieleicht auch 10%) liegt, würde ich insbesondere bei read only (wo man ja blocken kann) alles lesen und durch einen Filter rattern lassen, das ist dann auch am effektivsten.

D*B

[Fuerchau]

Wenn doppelte Schlüssel vorkommen können, lass das UNIQUE doch weg.

[Pikachu]

Es gibt nicht nur S für SELECT sondern auch noch O für OMIT.