SQL0030

[DKSPROFI]

Moin *all und ein frohes Neues Jahr,

der berühmte Wald…..

In einem Programm wird folgendes Statement gebaut:

Lesen Kundenstamm, dann Bau des Strings: „Select * from Datei (ist eine View) A, Artikelstammdatei B where v_kdnr = + %Char(KDNR) AND (V_KOONR = ArtNr)“

EXEC SQL Prepare K6S From : FetchString ;
EXEC SQL Declare K6C Cursor for K6S ;
EXEC SQL Open K6C ;
Dou 1 = 2 ;
EXEC SQL FETCH NEXT FROM K6C INTO : Ds_K0K6R ;
If SQLCOD Fehler oder Ende wech
EndIf
Mach was
EndDo ;

V_KDNR ist ein Feld aus der VIEW
V_KOONR ist ein Feld aus der VIEW, ArtNr der Feldname aus Datei B
KDNR ist ein Feld aus dem Kundenstamm

Setze ich das Statement interaktiv ab, dann ist alles in Ordnung. Das Programm läuft aber in einem Batchnachtjob, da werden dann aber Joblogs ohne Ende produziert. Der Inhalt ist identisch, immer der SQL-Fehler SQL0030 Anzahl der Host-Variablen geringer als die Ergebniswerte. Ich find da einfach den Fehler nicht.

Hat jemand von Euch eine Idee?


mfg


DKSPROFI

[B.Hauser]

Wieder ein Beispiel dafür, dass man dynamisches SQL und vor allem SELET * soweit möglich vermeiden sollte.

Dein Problem hat mit den V_ Feldern nichts zu tun, sondern die Anzahl der Felder in der Ausgabe-Datenstruktur stimmt nicht mit der Anzahl der ausgewählten Spalten überein. Hier musst Du ansetzen.

Birgitta

[DKSPROFI]

Hallo Birgitta,

vielen Dank für Deine Antwort. in diesem Fall lässt sich das nicht vermeiden. Das mit der Ausgabestruktur habe ich nicht geschnallt. Die Ds_K0K6R ist wie folgt definiert:
d Ds_K0K6R E DS EXTNAME(K0K6V) K0K6V ist die View

Ich bin der Meinung dass der Select doch auf die View geht, oder nicht?

mfg

DKSPROFI

[B.Hauser]

Aber Du Joinst die View mit dem Artikelstamm.
SELECT * beinhaltet also nicht nur die Felder aus der View sondern auch die Felder aus dem Artikelstamm.

Entweder musst Du Datenstrukturen für beide Dateien (View und Artikel-Stamm) im Fetch angeben.
Sofern nur die View benötigt wird, kannst Du auch mit SELECT View.* From View ... arbeiten.

... und nach meiner Erfahrung (und ich habe schon das eine oder andere embedded SQL Programm geschrieben) ist dynamsiches SQL nur notwendig wenn die Dateien nicht bekannt sind und dynamisch verwendet werden und das ist bei Anwendern i.d.R. meist nicht der Fall. Damit müssen sich (allenfalls) Toolhersteller rumschlagen.
Sowohl WHERE-Bedingungen als auch ORDER BY-Anweisungen können über statische Case-Anweisungen dynamisch gesteuert werden.

Ebenso ist i.d.R. ein SELECT * nicht erforderlich. Wenn man wirklich nur die notwendigen Daten selektiert und nicht jede Menge unnötiger Daten hin- und herschaufelt, kann man einiges an Datenbankenaktivität vermeiden.

Birgitta

[DKSPROFI]

Hallo Birgitta,

dass Du schon "das eine oder andere Programm" geschrieben hast, glaube ich der QUEEN of SQL unbesehen. Vielen Dank für Deine Antwort, ich denke dann ist wohl
Select
a.feld1
a.feld2
usw
b.feld1
b.feld2
usw
from Datei A, Artikelstammdatei B
where v_kdnr = : KDNR AND (V_KOONR = ArtNr)
sehr viel sinnvoller.

mfg

DKSPROFI

[Fuerchau]

Da du wohl alle Felder aus beiden Strukturen haben willst musst du auch beide Strukturen für die Zielausgabe haben.
Wobei ein dynamischer "Select *" bei Änderung der View/Tabelle dann wieder nicht funktioniert.
Warum machst du den dynamisch und nicht mit Hostvariablen statisch?

Wenn du nicht generell alle Felder benötigst solltest du nur die tatsächlich benötigten Felder aufführen und kannst dann im Fetch auch eine individuelle Struktur mit den Feldern verwenden.

[DKSPROFI]

Moin,

danke für Eure Antworten, jetzt sehe ich klarer.

mfg


DKSPROFI