Umstellung von DDS auf SQL

[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).