Feld per SQL hinzufügen!

[B.Hauser]

Per SQL geht das nur auf Tabellen, die auch mit SQL erstellt wurden

Das stimmt nicht!!!
ALTER TABLE kann auch für DDS beschriebene Tabellen ausgeführt werden.
... auch wenn ich das NICHT empfehlen würde.

Eine Spalte im DDS hinzufügen und dann ein CHGPF ausführen ist doch mindestens genauso einfach!

Beim CHGPF müssen logische Dateien weder gelöscht noch neu erstellt werden, noch müssen irgendwelche Constraints oder Trigger angefasst werden:

Einfach:

CHGPF FILE(MYLIB/MYFILE)
      SRCFILE(MYSRCLIB/QDDSSRC)
      SRCMBR(MYFILE)

ausführen.

Birgitta

[Fuerchau]

Man beachte aber, dass sich die Dateiebenen-ID ändert und alle Programme die auf die PF oder die LF's native zugreifen neu erstellt werden müssen !

Werden die Tabelle(n) nur per SQL verwendet, ist eine Erstellung der Programme nicht erforderlich.

@Birgitta
Danke für den Hinweis.
Besser wäre es gewesen, dies per SQL abzuweisen.

[svente]

Danke für die Tips. Mit ALTER TABLE hat es geklappt.

[kitvb1]

...
Werden die Tabelle(n) nur per SQL verwendet, ist eine Erstellung der Programme nicht erforderlich.
...

IIRC, Wenn man "SELECT * from ..." in eine Programm nutzt, muss man auch dann dieses Programm umwandeln. Wenn man "SELECT feld1, f2, ... from ..." nutzt, dann ist umwandeln nicht erforderlich.

[Fuerchau]

Wofür hat man denn SQL um gerade einen Select * nicht zu verwenden ?

[andreaspr@aon.at]

IIRC, Wenn man "SELECT * from ..." in eine Programm nutzt, muss man auch dann dieses Programm umwandeln. Wenn man "SELECT feld1, f2, ... from ..." nutzt, dann ist umwandeln nicht erforderlich.

Ein "Select *" ändert der Kompiler sowieso in ein "Select sp1, sp2, ..." um.
Wenn du dann eine Spalte hinzufügst wird werden beide Varianten nur jene Spalten selektieren, die zur Kompile-Zeit vorhanden waren.
Soll die neue Spalte im Programm auch selektiert werden, muss du so oder so das Programm neu umwandeln.
(Das ganze gilt jetzt mal nur für Statisches SQL!!)

[kitvb1]

I knew I should write it in english, I was concentrating too much on the German

If you use "select *" with "into" then you will most likely need to recompile. This, if you are not using a referenced DS.

But, if you are using something like "select count(*)" then you will not need to recompile.

[andreaspr@aon.at]

I knew I should write it in english, I was concentrating too much on the German

If you use "select *" with "into" then you will most likely need to recompile. This, if you are not using a referenced DS.

But, if you are using something like "select count(*)" then you will not need to recompile.

Du solltest mal ein Test-PGM erstellen, wenn du mir nicht glaubst
1. Die Externe-DS wird nicht zur Laufzeit erstellt, sondern zum Zeitpunkt der Umwandlung!
2. Ich selbst habe vor 1/2 Jahr ein Testpgm geschrieben, wo ich genau DAS herausfinden wollte. Ergebnis: Ein Select * wird in ein Select sp1, sp2, ... umgewandelt.
Das gleiche hast du ja auch wenn du eine View mit Select * erstellst. Wenn du dann mit DSPFD MYVIEW1 das View anschaust, wirst du von deinem Select * nicht viel finden, sondern vielmehr eine Aufschlüsselung der Spalten.

lg

[B.Hauser]

... es ist schon klar, dass SELECT * intern aufgelöst wird!

Das Problem, auf das Kit hinweisen möchte, tritt beim Fetch oder beim Select into auf!

Werden die Daten in eine (externe) Datenstruktur basierend auf der Datei oder View ausgegeben, muss bei einer Änderung (der Tabelle oder View), bei der Felder/Spalten hinzugefügt, gelöscht oder verändert werden, das Programm neu kompiliert werden, damit in RPG der Datei-Aufbau erneut korrekt übernommen wird.

Wird in einer Tabelle oder View lediglich ein Feld am Ende hinzugefügt ist bei LVLCHK(*NO) eine erneute Kompilierung nicht notwendig.

Ein SELECT * sollte jedoch bei der Arbeit im (embedded) SQL soweit möglich vermieden werden.
Hierfür gibt es zwei Gründe:

1. Der erste wurde gerade lange und breit diskutiert, d.h. werden Felder/Spalten direkt ausgewählt, ist bei Datei-Erweiterung eine Kompilierung der Programme nicht erforderlich.
2. Der zweite Grund ist Performance. Im Gegensatz zu RPG bei dem immer der ganze Satz gelesen werden muss, werden bei SQL nur die Daten, die auch angefordert werden zurückgegeben. Werden die gewünschten Daten eingeschränkt, sind weniger Zugriffe auf die Datenbank erforderlich und müssen weniger Daten in den Speicher geladen werden.

Birgitta

[Fuerchau]

Letzteres bezweifle ich da eher.
Wenn man sich die Aufrufhierarchie bis hin zur PF ansieht, wird beim Lesen/Schreiben ein interner Satzpuffer verwendet der immer den kompletten Satz beinhaltet.
Auch SQL muss letztlich die nativen File-IO's verwenden, die auch HLL's verwenden.
Was gespart wird, sind letztlich die Moves zwischen Filepuffer und Datenfeld, wobei diese sich bei SQL sogar erhöhen da der Move zwischen den automatisch generierten SQLxxx-Variablen und den Hostvariablen noch hinzu kommt.

Wenn ich in RPG eine Datei verarbeite und die Felder nicht zusätzlich als DS definiere, werden auch nur die verwendeten Felder zwischen Puffer und Feld bewegt.

Wenn man dann also letztlich SQL mit RPG oder sogar COBOL vergleicht, so ist COBOL im Microsekundenbereich halt immer noch am schnellsten, da hier letztlich mit dem internen IO-Puffer gearbeitet wird und zusätzliche Moves vermieden werden.

SQL hat letztlich den großen Vorteil, dass man hier halt Zugriffslogiken in die Datenschicht verlegt und sich das Leben insbesonders bei Massenverarbeitung oder komplexen Gruppierungen/Summen oder sonstigen Berechnungen erleichtern kann.

[andreaspr@aon.at]

@Birgitta: Was das ursprungsthema betrifft, ist es klar, wenn Felder entfernt oder geändert werden, dass das PGM neu umgewandelt werden muss. Hier gings nur ums Hinzufügen und da ist ein neu umwandeln (wie du eh geschrieben hast) nicht notwendig. Ist aus der Diskussion vielleicht nicht ganz herauszulesen.

@Spaltenauswahl: In bestimmten Fällen verwende ich auch kein Select * sondern wähle die Spalten direkt aus die ich benötige, da wenn ein Index existiert, in dem diese Spalten als Key-Felder vorhanden sind, ersparrt sich die DB ein Index Probe.
Die Datenbank muss dann nicht auf die PF zurückgreifen, da alle Infos in der LF vorhanden ist. (--> Index Access Only)
Und das sparrt bei großen und komplexen Abfragen vieeel Zeit!

[Fuerchau]

Index-Access-Only heißt, dass alle Felder des Select's Bestandteil des Index sind.
Fehlt nur ein Feld, muss trotzdem auf die PF zugegriffen werden.