Anzahl der Host-Variablen geringer als die Ergebniswerte.

[RobertMack]

Anzahl der Host-Variablen geringer als die Ergebniswerte.

Das riecht irgendwie nach einem Select * from GeänderteDatei into FestCodierteDS ...

[BenderD]

Das riecht irgendwie nach einem Select * from GeänderteDatei into FestCodierteDS ...

... auch das ein Kunstfehler. Alle SQL Zugriffe gehen ausschließlich auf Views, die sich nie ändern und stets mit select * unter Verwendung externer Datenstrukturen. Zusätzliche Felder o.ä. werden in neuen Views sichtbar - voila.

D*B

[Andreas_Prouza]

Ich würde hier einfach den DB Monitor starten und entsprechende Filter (Job, Tabelle, ...) hinterlegen erneut ausführen und den Report anzeigen lassen.
Dort siehst du dann auch die ganzen Details.

[Fuerchau]

Das ist nicht korrekt. Ein "select *" wird von der Compilezeit bereits aufgelöst.
Eine Änderung der Tabelle hat da keine Auswirkung.

Wenn man allerdings mit dynamischen SQL's arbeitet verbietet sich ein "Select *" von selbst, da dieser tatsächlich zur Laufzeit aufgelöst wird.

[Andreas_Prouza]

Genau, oder so wie Robert geschrieben hat, wenn die Ziel-DS hardcoded erstellt wurde, die Tabelle geändert und dann das Programm neu kompiliert wurde.
Dann sind die neuen Spalten der Tabelle im Zugriff, aber noch die alte Datenstruktur, wenn diese nicht ebenfalls mit angepasst wurde.

[Fuerchau]

Das würde beim Compile bereits auffallen und wer schreibt die DS noch selber, wenn ich einen Bezug zur Datei machen kann?

[BenderD]

... alle diejenigen, die vom select * abraten und das sind ja nicht wenige "Experten"!

[B.Hauser]

Das würde beim Compile bereits auffallen und wer schreibt die DS noch selber, wenn ich einen Bezug zur Datei machen kann?

Nicht zwangsläufig! Solange die Spalten-Definitionen (in der Reihenfolge) übereinstimmen bzw. compatibel sind und lediglich weniger Ausgabe-Felder vorhanden sind als ausgewählt, wird das Programm erstellt.

SQL0030 (Anzahl der Host-Variablen geringer als die Ergebnis) hat Severity 0 und verursacht somit keinen Fehler.
Im (RPG) Programm selber wird lediglich eine Warnung mit SQLCODE +30 ausgegeben. Die Daten werden jedoch korrekt ausgegeben.
... das einzige ist, die störende Meldung
und ggf. tatsächlich eine Beendigung der Verarbeitungsschleife, weil der Programmierer mal wieder (entgegen aller Empfehlungen) auf SQLCODE = 0 oder SQLSTATE = 00000 prüft.

Im Übrigen kommen solche "Fehler" auch häufig vor, wenn 2 Tabellen verjoint werden und alle Felder mit SELECT * ausgewählt werden und der Programmierer sich entscheidet, dass nur die Daten der ersten Datei benötigt werden und im Fetch nur die Datenstruktur der ersten Datei angegeben wurde.

SELECT * sollte man m.E. grundsätzlich vermeiden und immer nur genau die Spalten auswählen die man auch wirklich benötigt, auch wenn man wie Dieter für jede Abfrage eine View baut.
Vielleicht braucht man die gleiche View doch mehrfach und möchte dann irgendwann Spalten hinzufügen ...

Birgitta

[BenderD]

SELECT * sollte man m.E. grundsätzlich vermeiden und immer nur genau die Spalten auswählen die man auch wirklich benötigt
Birgitta

... das hat erhebliche Folgerungen:
- erhöhter Programmieraufwand
- man kann keine externen Datenstrukturen verwenden
- Fehler in der Feldreihenfolge führen zu tückischen Fehlern
- Redesign Schritte an der Datenbank sind aufwändig und fehlerträchtig
- massive Performance Einbrüche bei remote Zugriffen mit dynamischem SQL

D*B

[ExAzubi]

... das hat erhebliche Folgerungen:
- erhöhter Programmieraufwand
- man kann keine externen Datenstrukturen verwenden
- Fehler in der Feldreihenfolge führen zu tückischen Fehlern
- Redesign Schritte an der Datenbank sind aufwändig und fehlerträchtig
- massive Performance Einbrüche bei remote Zugriffen mit dynamischem SQL

Da kann ich Dieter nur Recht geben! Brauche ich nur 1-3 Felder einer Datei, dann mache ich eine ZielDS oder gezielt in Host-Variablen.

Brauche ich aber >5 Felder einer Tabelle, dann mache ich Select * mit einer E DS.

Und RPG ist da nicht die einzige Sprache die eine solche Funktionalität zur Verfügung stellt. Auch in ABAP kann das so gemacht werden.

[Fuerchau]

Tja, da zeigt sich mal wie immer: Man muss wissen was man tut;-).
Einen Performanceunterschied zwischen Select * und Select f1, f2 ... konnte ich bisher nicht feststellen.
Der interne DB-Read liest sowieso den ganzen Satz und die SQL-Runtime macht dann nur noch ein paar Moves. Bei sinnvoller Verwendung von "DataPointern" (Zeiger auf Daten mit Feldspezifikation) werden die das wohl sinnvoll implementiert haben. Auch im RPG findet man dann nur Moves.
Und Millionen von Moves sind immer noch schneller als 1000de von Read's.

Anders siehts tatsächlich bei remoten DB's aus, da ich gezielt durch Angabe der Felder weniger Daten übertragen muss.

Und was den Join-Quatsch angeht.
Selbst da könnte ich einen "Select a.* from a inner join b on ..." durchaus machen, wobei da ein "where exists " durchaus sinnvoller ist.

[BenderD]

Tja, da zeigt sich mal wie immer: Man muss wissen was man tut;-).
Einen Performanceunterschied zwischen Select * und Select f1, f2 ... konnte ich bisher nicht feststellen.
Der interne DB-Read liest sowieso den ganzen Satz und die SQL-Runtime macht dann nur noch ein paar Moves. Bei sinnvoller Verwendung von "DataPointern" (Zeiger auf Daten mit Feldspezifikation) werden die das wohl sinnvoll implementiert haben. Auch im RPG findet man dann nur Moves.
Und Millionen von Moves sind immer noch schneller als 1000de von Read's.

Anders siehts tatsächlich bei remoten DB's aus, da ich gezielt durch Angabe der Felder weniger Daten übertragen muss.

Und was den Join-Quatsch angeht.
Selbst da könnte ich einen "Select a.* from a inner join b on ..." durchaus machen, wobei da ein "where exists " durchaus sinnvoller ist.

... bei remote Verarbeitung werden niciht nur Daten, sondern auch die Statements übertragen!!!
Ich erinnere mich da an einen Kunden, der von "Experten" beraten wurde und denen man eine "Modernisierung" verkauft hat. Da wurden alle Quellen mit Tools nach total free RPG konvertiert, anschließend hat man sich nicht getraut das auch zu wandeln und in Produktion zu setzen und festgelegt das bis zur jeweils nächsten Änderung eines Programms zu verschieben. Dann hat man alle DDS erstellten Dateien nach SQL beschriebenen umgesetzt und dabei Autoincrement keys, und Timestamps für Anlage und Änderung zugefügt, sowie alle Feldnamen sprechend gemacht und gravierend verlängert. Da alle Programme mit RLA zugreifen, hat man anschließend die alten DDS LFs wieder draufgesetzt und alle Keybeziehungen, wie vorher wieder hergestellt.
Anschließend wollte man die Datenbank dann auf einen MS SQL-Server verschieben. Select * war dabei genauso verboten, wie die Erstellung "unnötiger" Views. Im proof of concept zeigte sich dann, das die Übertragung der überlangen SQL Statements mehr ausbremste, als eventuell unnötige Felder.

Gegen das Weglassen nicht benötigter Felder ist nichts einzuwenden (oft sind in Dateien mehr nie sinnvoll gefüllter Felder als tatsächlich benutzter), dann aber per View mit Select * und externen Datenstrukturen.

D*B