Feld per SQL hinzufügen!

[svente]

Servus,

gibt es eine Möglichkeit per SQL einer bestehenden Datei ein oder mehrere Felder hinzuzufügen?

Danke und Gruß.

Svente

[Fuerchau]

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

alter table mytable add Fieldxxx ...

[svente]

Die ist leider nicht mit SQL erstellt worden.

[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