Umstellung von DDS auf SQL

[BenderD]

Einspruch euer Ehren, in mehreren Punkten:

ad Formatnamen: der ist für SQL Zugriffe völlig Banane

ad select *: der * wird beim Compile aufgelöst, sprich das läuft bei zusätzlichen Feldern unverändert weiter; bei der nächsten Änderung (sprich recompile) wird das zusätzliche Feld erst sichtbar.

ad Sperren: beim Update nach Cursor sperrt DB2/400 den zuletzt gelesenen Satz auch ohne Commit, das läuft dann ziemlich analog zu Rekord Löffel.

ad Commit Level: bei korrektem Einsatz wird hier vieles möglich, was bei Rekord Löffel Ekzem garnicht geht. Zum Beispiel konsistente Auswertungen während laufender Transaktionen (gerade weil es hier Sperren gegen lesen gibt) - mit Rekord Löffel Ekzem kann man nicht sicher stellen, dass eine Saldenübersicht im Tagesbetrieb ausgeglichenen Saldo liefert.

ad Tipparbeit: bei voller Nutzung von SQL hört das Sätze zusammen klappern (read, setll, reade, Schlüssel besetzen, chain, Schlüssel besetzen chain...) auf und die Tiparbeit nimmt drastisch ab!

ad laufende Nummern: dafür gibt es extra einen Feldtyp mit AUTOINCREMENT, da gibt es im Programm nix zu tippen.

mfg

Dieter Bender,

der in einem völlig übereinstimmt: ohne Umdenken im Anwendungsdesign und ohne solide Kenntnisse wird das eher nix.

Über eins sollte man sich im Klaren sein:
Bei SQL ist mehr Definitions und Tiparbeit gefragt, wenn man's denn richtig machen will.

Dateien, die per CREATE TABLE erstellt werden, erhalten als Formatnamen den Namen der Tabelle.

Man sollte nie "SELECT *" verwenden, da sonst eben wieder mehrfach umgewandelt werden muss (Tiparbeit).

Normalerweise sperrt ein SELECT nie !!!
Also Vorsicht bei UPDATE (neues Konzept) !
Um Sperren beim SELECT zu erhalten, hilft nur Journaling und CMTLVL(*ALL), was allerdings immer noch nicht das Lesen durch andere Programme verhindert.

Neue Daten können nur per INSERT erstellt werden, auch hier ist Tiparbeit wieder gefragt.

Da beim INSERT jedoch nicht immer alle Felder benannt werden müssen, ist beim CREATE TABLE über NULL-Werte bzw. Defaults nachzudenken, ggf. sind Trigger nötig.

Häufig werden für laufende Nr'n einfach CHAIN/ADD 1/UPDAT kodiert, das funktioniert so nicht mehr sicher.
Hier sind ggf. Generatoren nötig bzw. eben neue Konzepte.

Es gibt da sicherlich noch viele weitere Punkte, jedoch ist eins sicher:
SQL erfordert ein Redesign einer Anwendung, da sonst unerwartete Ergebnisse sehr wahrscheinlich werden.

[B.Hauser]

Hallo,

ad Formatnamen:
Formatnamen sind nur für native RPG I/O notwendig. Wenn die bisherigen Anwendungen nach Konvertierung in SQL beschriebene Dateien ohne Änderung weiterlaufen sollen, müssen die SQL Tabellen einen anderen Formatnamen erhalten.
Um dies zu realisieren gibt es 2 Möglichkeiten:

1. Vor Release V5R4: Die SQL Tabelle mit dem Formatnamen als Dateiname erstellen (Dateiname=Formatname) und anschliessend mit Rename in den echten Feldnamen umbenennen. Bei der Umbenennung bleibt der Formatname unverändert.
2. Ab Release V5R4 kann für SQL Tabellen und Views ein abweichender Satz-Formatname über das Schlüsselwort RCDFMT direkt im CREATE TABLE-Statement angegeben werden.

ad laufende Nr.: Laufende Nr. werden über eine Identity Column gesteuert. Pro Tabelle darf genau 1 Identity Column angegeben werden. Bei dieser Spalte muss als numerischer Datentyp definiert sein. Start, Ende, sowie Schrittgröße und die Aktion bei Überlauf können festgelegt werden. Über die Spalte muss ein Unique-Index generiert werden, da die Datei nicht geprüft wird, sondern immer er nächste gecachte Wert verwendet wird. Wird bei Überlauf wieder von vorne angefangen, könnten Duplikate erzeugt werden.

CREATE TABLE MySchema/MyTable
   (Id INTEGER GENERATED ALWAYS AS IDENTITY
      (START WITH 10 , INCREMENT BY 10), 
    weitere Felder...)
RcdFmt MyTableF; 

Die Identity Column wird beim Schreiben eines neuen Satzes automatisch gefüllt. (auch dann, wenn der Satz über native I/O erstellt wird.)

Wenn es nur darum geht, die DDS beschriebene Tabellen in SQL definierte Tabellen zu verwandeln, kann iSeries Navigator Reverse Engineering verwendet werden.
Im iSeries Navigator Database auf die physische Datei positionieren, Rechts Click und SQL generieren. Aus der DDS beschriebenen Tabelle wird ein SQL Skript erstellt. Schlüsselworte, die von SQL nicht unterstützt werden (z.B. DATFMT, EDITC) werden gekennzeichnet.

Um ein neues Design zu ermöglichen, würde ich die SQL Tabellen mit einem anderen Namen als die ursprüngliche physische Datei erstellen. Anschliessend eine SQL View mit dem Original-Dateinamen, die die Felder in der physischen Datei 1:1 abbildet. Anstatt direkt auf die physische Datei zuzugreifen, die View verwenden.

Über die View können (ab Release V5R4) Instead Of Trigger für Insert, Update und Delete erstellt werden. Der Vorteil von Instead of Triggern ist, dass durch sie verknüpfte SQL-Views upgedatet werden können.

Birgitta

[dinie]

Hallo Artur, nochmals zum DDS: wenn du das neue Feld in deine Datei hinten ran hängst, und deine Datei mit LVLCHK(*NO) umwandelst, brauchst du nicht alle Programme zu wandeln die diese Datei benützen. Ausnahme sind Programme mit embedded SQL, diese solltest du wandeln.
Gruß Dinie.

[Fuerchau]

Gerade embedded SQL benötigt KEINE neue Umwandlung, das ist ja gerade der Vorteil (Ausnahme SELECT * ).

Mit LVLCHK(*NO) müssen auf jeden Fall die Programme gewandelt werden, die einen WRITE haben, da es sonst z.B. zu Dezimalfehlern (falscher DB-Inhalt) beim WRITE kommt.

[BenderD]

SELECT * auch nicht!!!

Gerade embedded SQL benötigt KEINE neue Umwandlung, das ist ja gerade der Vorteil (Ausnahme SELECT * ).

Mit LVLCHK(*NO) müssen auf jeden Fall die Programme gewandelt werden, die einen WRITE haben, da es sonst z.B. zu Dezimalfehlern (falscher DB-Inhalt) beim WRITE kommt.

[Joe]

Gerade embedded SQL benötigt KEINE neue Umwandlung, das ist ja gerade der Vorteil (Ausnahme SELECT * ).

Mit LVLCHK(*NO) müssen auf jeden Fall die Programme gewandelt werden, die einen WRITE haben, da es sonst z.B. zu Dezimalfehlern (falscher DB-Inhalt) beim WRITE kommt.

Umwandlung bei Select * ist m.E. notwendig da hierzu in der Regel eine Datenstruktur notwendig ist. (Select * into Datenstruktur) deren Aufbau erst bei erneutem Compile den Felden der Tabelle entspricht.

Gruß Joe

[BenderD]

das ist keine Meinungsfrage, eine Datenstrukturdeklaration (extern oder auch nicht) wird zur Compiletime aufgelöst, SELECT * generiert denselben Code wie SELECT from blablabla, solange zur Laufzeit alles Feldweise Typverträglich ist, ist es der Runtime völlig schnurz wie die Felder mittlerweile aussehen. Das ganze funktioniert ebenfalls, wenn ich Felder in der Größe oder Skalierung ändere (schließlich kann ich in SQL ein 10 stelliges numerisches Feld ohne Nachkomma auch in ein 12 stelliges mit 4 Nachkommastellen einlesen); solange ich nicht kompiliere bleibt alles wie gehabt. Nach dem Compile werden die externen Datenstrukturen und die select * Anweisungen neu aufgelöst.
Bei SQL werden keine Buffer blind übereinander gehuddelt, da brauchts keine Löffel-Prüfung und abstellen kann man da Prüfungen schon garnicht!

mfg

Dieter Bender

Umwandlung bei Select * ist m.E. notwendig da hierzu in der Regel eine Datenstruktur notwendig ist. (Select * into Datenstruktur) deren Aufbau erst bei erneutem Compile den Felden der Tabelle entspricht.

Gruß Joe

[Fuerchau]

Bei Feldtypänderungen ist auch meistens ein Recompile erforderlich, da es zur Laufzeit ggf. zu Konvertierungsproblemen kommt (insbesonders zu lang beim Lesen).

[BenderD]

Natürlich muss man irgendwann Programme ändern, wenn man erweiterte Feldtypen oder zusätzliche Felder nutzen will. Im Unterschied zu RLA ergibt das bei SQL bei korrekter Vorgehensweise nie die Notwendigkeit von Big Bang Umstellungen; man kann das bequem in Stufen machen, wie der Bauer die Klöße isst: einen nach dem andern.

mfg

Dieter Bender

Bei Feldtypänderungen ist auch meistens ein Recompile erforderlich, da es zur Laufzeit ggf. zu Konvertierungsproblemen kommt (insbesonders zu lang beim Lesen).