DDS COMP

[Fuerchau]

Je nach Datenvolumen ist die Abfrage "a + b + c <> 0" nicht so schnell, da normalerweise kein Index vorhanden ist.
Man muss da schon einen "calculated" Index erstellen und die SQL-Abfrage dann genau so gestalten.

Native ohne SQL ist das leider ohne eine Dateiänderung nicht möglich.
DDS lässt keine Berechnung (nur CAT und SST) zu.

Eine View ist native quasi nur als InputPrimary zu verarbeiten da sie
- keine Sortierung
- keine Schlüssel
enthält.

[B.Hauser]

Ich weiß jetzt nich in wieweit der Kunde SQL Indices aktzeptiert, aber es wäre durchaus möglich einen SQL Index mit den entsprechenden Selektionen zu erstellen.

CREATE INDEX YourSchema/YourIndex 
    ON YourSchema/YourTable (KeyFld01, KeyFld02 ... KeyFld0N) 
    WHERE (Menge1 - Menge2 - Menge3) = 0 
RCDFMT YourRcdFmt ADD ALL COLUMNS;

Das schöne ist an SQL Indices, sie können wie ganz normale geschlüsselte logische Dateien mit native I/O verarbeitet werden. Das ist übrigens nichts neues, SQL Indices konnten schon in den 4er Releasen mit Native I/O verarbeitet werden.
Die Erweiterungen, dass neue Spalten generiert werden können und Where-Bedingungen hinzugefügt werden können, gibt es seit Release 6.1. Und in Release 6.1 war die Erweiterung in erster Linie für native I/O gemacht. Erst ab 7.1 und später kann SQL selber nach und nach solche Indices richtig verwenden.
Da SQL in bei der Erstellung von Indices verwendet werden kann, sind sie um einiges mächtiger als DDS beschriebene logische Dateien.

Birgitta

[harkne]

Hallo Birgitta,

danke für die Antwort, aber leider müssen wir die Dateien sowohl PF als auch LF über DDS erstellen. Die ganze Problematik hat sich aber jetzt sowieso erledigt, da ich nach Absprache ein Flag einfügen kann auf das ich dann meinen COMP mache.

Vielen Dank für die Hilfe

[B.Hauser]

Vielleicht solltest Du mal Deinen Kunden oder Chef dezent darauf hinweisen, dass DDS "stabilized" ist, und das bereits seit Release V5R3 (da gab es die letzte Änderung).
Alle neuen Änderungen nur in SQL erfolgen, auch die die "Erweiterung" des DDS betreffen. Release 6.1 war sogar ein Release, in dem man sich in erster Linie um Erweiterungen in SQL für naitve I/O gekümmert hab.

Empfehlung der IBM ist es alle neuen Datenbankenobjekte nur mit SQL zu erstellen und die vorhandenen peu à peu zu konvertieren.

Leider tragen solche "hartgesottenen Ignoranten" auch maßgeblich dazu bei, dass die IBM i den Ruf als veraltet und überholt hat, obwohl sie eigentlich die modernste Maschine ist. Man schmeißt im Endeffekt lieber die ganze Maschine mit allem drum und dran raus zugunsten einer Umgebung, in der DDS und native I/O eh' keine Rolle mehr spielen, als die vorhandenen Möglichkeiten zu nutzen.

Birgitta

[harkne]

Eine Frage dazu.

Habe ich die möglichkeit das SQL-Statement irgendwo abzulegen so wie die DDS um es immer wieder neu erstellen zu können ?
Oder vielleicht anders. Ich denke mal das Hauptproblem ist, das es für alles eine Quelle gibt und bisher war es auch für die Dateien so. Wie wird das bei Euch gehandhabt. Kann man irgendwo das SQL-Statement als Quelle ablegen und dann auch mit einer Auswahl im PDM erzeugen ?
Ich habe bisher nur mit STRSQL und embedded SQL im RPG gearbeitet.

Viele Grüße Harkne

Vielleicht solltest Du mal Deinen Kunden oder Chef dezent darauf hinweisen, dass DDS "stabilized" ist, und das bereits seit Release V5R3 (da gab es die letzte Änderung).
Alle neuen Änderungen nur in SQL erfolgen, auch die die "Erweiterung" des DDS betreffen. Release 6.1 war sogar ein Release, in dem man sich in erster Linie um Erweiterungen in SQL für naitve I/O gekümmert hab.

Empfehlung der IBM ist es alle neuen Datenbankenobjekte nur mit SQL zu erstellen und die vorhandenen peu à peu zu konvertieren.

Leider tragen solche "hartgesottenen Ignoranten" auch maßgeblich dazu bei, dass die IBM i den Ruf als veraltet und überholt hat, obwohl sie eigentlich die modernste Maschine ist. Man schmeißt im Endeffekt lieber die ganze Maschine mit allem drum und dran raus zugunsten einer Umgebung, in der DDS und native I/O eh' keine Rolle mehr spielen, als die vorhandenen Möglichkeiten zu nutzen.

Birgitta

[B.Hauser]

Habe ich die möglichkeit das SQL-Statement irgendwo abzulegen so wie die DDS um es immer wieder neu erstellen zu können ?

Natürlich!
Du kannst SQL Scripte entweder im IFS oder als Source Physiscal File Member ablegen.
Mit RUNSQLSTM kannst Du diese Scripte jederzeit wieder ausführen.

Wir legen die Erstellungsbefehle für Datenbankenobjekte (wie DDS) als Teildateien ab (auch alte Schule!). Ich habe z.B. bei uns im PDM den RUNSQLSTM-Befehl hinterlegt. Anstatt jetzt ein Datenbanken-Objekt mit 14 zu erstellen wird die Auswahl RS verwendet.

Wenn man im RUNSQLSTM in der Option DFTRDBCOL die Objekt-Bibliothek mitgibt, kann man sogar die Qualifizierung mit der Bibliothek in den Skripten weglassen. Über das gleiche Skript könnte somit das Objekt in unterschiedlichen Schemata/Bibliotheken (Test/Echt) erstellt werden.

Die andere Alternative ist, die Teildatei mit dem IBM i Navigator - Run an SQL Script/Eine SQL Prozedur ausführen öffnen und anschließend ausführen.

Die SQL Skritpe können aus dem Datenbanken-Objekt über den IBM i Navigator generiert und wahlweise im IFS oder als Teildatei gespeichert werden.

Mit einem der letzten Technology Refreshes wurde auch die Stored Procedure GENERATE_SQL in der Bibliothek QSYS2 bereitgestellt, über die die SQL Skripte ebenfalls generiert und wahlweise ins IFS oder als Teildatei abgelegt werden können.

Noch ein Tip: STRSQL ist genaus "stabilized" wie DDS.
Aktuell ist das Strategische Produkt der IBM der IBM i Navigator (Client Access und Teile sind auch in der Web-Version realisiert).
IBM Data Studio wäre u.U. eine Alternative.
Man sollte sich langsam mit diesen Tools anfreunden.


Birgitta

[harkne]

Vielen Dank für die ausführliche Info.

Ich werde das mal bei uns im Haus weiter geben.

Natürlich!
Du kannst SQL Scripte entweder im IFS oder als Source Physiscal File Member ablegen.
Mit RUNSQLSTM kannst Du diese Scripte jederzeit wieder ausführen.

Wir legen die Erstellungsbefehle für Datenbankenobjekte (wie DDS) als Teildateien ab (auch alte Schule!). Ich habe z.B. bei uns im PDM den RUNSQLSTM-Befehl hinterlegt. Anstatt jetzt ein Datenbanken-Objekt mit 14 zu erstellen wird die Auswahl RS verwendet.

Wenn man im RUNSQLSTM in der Option DFTRDBCOL die Objekt-Bibliothek mitgibt, kann man sogar die Qualifizierung mit der Bibliothek in den Skripten weglassen. Über das gleiche Skript könnte somit das Objekt in unterschiedlichen Schemata/Bibliotheken (Test/Echt) erstellt werden.

Die andere Alternative ist, die Teildatei mit dem IBM i Navigator - Run an SQL Script/Eine SQL Prozedur ausführen öffnen und anschließend ausführen.

Die SQL Skritpe können aus dem Datenbanken-Objekt über den IBM i Navigator generiert und wahlweise im IFS oder als Teildatei gespeichert werden.

Mit einem der letzten Technology Refreshes wurde auch die Stored Procedure GENERATE_SQL in der Bibliothek QSYS2 bereitgestellt, über die die SQL Skripte ebenfalls generiert und wahlweise ins IFS oder als Teildatei abgelegt werden können.

Noch ein Tip: STRSQL ist genaus "stabilized" wie DDS.
Aktuell ist das Strategische Produkt der IBM der IBM i Navigator (Client Access und Teile sind auch in der Web-Version realisiert).
IBM Data Studio wäre u.U. eine Alternative.
Man sollte sich langsam mit diesen Tools anfreunden.


Birgitta

[Robi]

Etwas 'unglücklich' ist die sql Version trotzdem.
mit DDS hab ich die Datei angelegt und, wenn Felder hinzu kamen, diese in die DDS eingefügt und ein CHGPF gemacht. Brauchte ich die Datei woanders konnte ich Sie mit CRTPF erstellen.

Mit SQL pflege ich entweder mehrere Sourcen
--> Create Table ...
und, für jede Änderung, ein "alter table" mit den neuen Felder sowie eine Anpassung im Create Table.
Wenn mir (und ich habe solche Kunden) die Reihenfolge der Felder nicht egal ist, muß ich wie zu Zeiten vor CHGPF die Datei mit Map und Drop hin und her kopieren.

und jetzt hoff ich, das Ihr schreibt das das alles nicht stimmt! Wir machen das nämlich (teilweise) so
und da war DDS erheblich komfortabler!

Robi
(der gerne SQL verwendet aber nicht glaubt das alles neue 'per Se' besser ist)

[RobertMack]

(der gerne SQL verwendet aber nicht glaubt das alles neue 'per Se' besser ist)

Like = *On;

If AllSql = *On;
MaintCostPerLine = 'more expensive';
EndIf;

[camouflage]

Like = *On;

If AllSql = *On;
MaintCostPerLine = 'more expensive';
EndIf;

Nicht doch...

wenn schon, nimm "true" und "false". Wer wird denn noch mit Indikatoren...

[Fuerchau]

Wenn man schon mit SQL arbeitet, ist die Reihenfolge der Felder in der Tabelle vollkommen egal.
Es ist schon AS/400-spezifisch, beim Hinzufügen von Feldern die Tabelle neu zu erstellen.
Sicherlich passiert dies nun automatisch, aber ein CPYF (Intern) sowie der doppelte Platz ist immer noch nötig. Andere DB's hängen das Feld einfach hinten dran und gut ist.

Problematisch ist das Einfügen von Feldern für jedes Programm, dass mit "Select *" in eine DS einliest.
Angehängte Felder werden ignoriert, dazwischen geschobene Felder führen (außer wenn alles CHAR ist) zu Fehlern beim Fetch (aufgelöste Moves).
Wenn alles CHAR ist merkt das Programm im Zweifel nichts und arbeitet mit falschen Feldinhalten.

[B.Hauser]

Mit TR2 für Release 7.2 bzw. TR10 Release 7.1 wird der CREATE TABLE-Befehl auf CREATE OR REPLACE erweitert, mit dem u.a. Spalten dazwischen geschoben werden können, Spalten verändert oder hinzugefügt werden können.
Man braucht keine unterschiedlichen Quellen mehr, sondern kann ein und das selbe Skript modifizieren und erneut ausführen (funktioniert wie CHGPF! - Alter Table ist nicht mehr notwendig)
Klappt übrigens auch mit einem CREATE TABLE, der auf einen SELECT basiert. Damit kann auch das Problem von Feld-Referenz-Dateien einfach gelöst werden.

Birgitta