SQLGetData richtig aufrufen

[Fuerchau]

Bei BLOB's muss man unterscheiden, ob die Daten direkt (SQL_BLOB, SQL_CLOB, SQL_DBCLOB) bearbeitet oder als sog. LOB_LOCATOR.
Technisch gesehen ist die Arbeit mit LOCATOR einfacher, da nicht der gesamte BLOB gelesen wird. Vor allem nicht, wenn man ihn vielleicht gar nicht benötigt.

Über den Locator erhält man ein Handle, für den dann extra Zugriffe benötigt werden (SQLGetSubString):
http://publib.boulder.ibm.com/iserie...rzadpmst82.htm

Prüfe mal den Feldtyp, der beim DescribeCol übergeben wurde.

[sim]

Bei BLOB's muss man unterscheiden, ob die Daten direkt (SQL_BLOB, SQL_CLOB, SQL_DBCLOB) bearbeitet oder als sog. LOB_LOCATOR.
Technisch gesehen ist die Arbeit mit LOCATOR einfacher, da nicht der gesamte BLOB gelesen wird. Vor allem nicht, wenn man ihn vielleicht gar nicht benötigt.

Über den Locator erhält man ein Handle, für den dann extra Zugriffe benötigt werden (SQLGetSubString):
http://publib.boulder.ibm.com/iserie...rzadpmst82.htm

Prüfe mal den Feldtyp, der beim DescribeCol übergeben wurde.

übergeben wurde SQL_VARCHAR

[Fuerchau]

Das hat mit BLOB's ja nichts zu tun.

Du musst bei SQLBindCol die Länge eines Feldes abhängig vom Feldtyp übergeben.
Bei SQL_DECIMAL, SQL_NUMERIC also 'Stellen * 256 + Nachkomma', bei Zeichenfeldern aber wieder Original '%size(MyField)'.
Du benötigst also verschiedene SQLBindCol !

Die ILE-Definition des VARCHAR-Feldes ist:

D MyVarChar s 10000 varying

Wobei das Feld dann tatsächlich 10002 Bytes groß ist, 2 Byte für die Länge des Inhaltes.
%size(MyVarChar) liefert die physische Größe, also 10002
%len(MyVarChar) liefert die Länge des Netto-Inhaltes

[sim]

** Hand vor den Kopf schlag **

Klar, so bau ich mir auch meine Ergebnis_ds zusammen.
Das mit den verschiedenen SQLBindCols funktioniert.
Hab jetzt 3 verschiedene Aufrufe gemacht. Bin zwar noch skeptisch ob das alle für mich in Frage kommenden Feldtypen abdeckt, aber schau' mer mal......

Danke für die schnelle Hilfe.

sim

[Fuerchau]

Wofür schlägst du dich denn mit den CLIAPI's rum ?
Gehts nicht mit Standard-SQL bzw. dynamischem SQL ?

[sim]

Nun ja, für einfache Sachen verwenden wir dies auch.

Im Moment haben wir schon ein selbst gestricktes Serviceprogramm bzw ne Prozedur an der man jegliche Art von SELECT-Statement übergeben kann und die dann ein Ergebnis Feld zurückliefert das dann einfach in die entsprechende ds gestellt werden kann

Bsp:
dow sql_exec('select feld1, feld2, feld3, .... from datei... where....');
kunden_ds = sql_ergebnis
....
enddo;

wobei kunden_ds ne datei bschreibt (extname....)

Dies haben wir per SQLDA lösen können.


Das Problem hierbei ist das immer nur ein SQL-Statement ausgeführt werden kann. Dadurch ist es nicht möglich verschachtelte SQL Abfragen mit diesem Tool zu erstellen.

Wenn wir dies über die APIs hinkriegen kann ich dies ja selber steuern und somit auch mehrere SQL's
verschachtelt ausführen.


Das andere wäre ja auch zu einfach. ;-)

Praktisch wäre natürlich ne RPG Anweisung a la: %sql
*träum*

[Fuerchau]

Aber wie hältst du es dann mit den variablen Strukturen und Feldtypen ?

Die Service-Routine müsste Funktionen wie Open(SqlString), GetField(Name), Close() usw. anbieten, da ja über die Struktur variabler Felder erst zur Laufzeit etwas bekannt ist.

Das RPG-Programm selber kann ja nicht mit dynamischen Strukturen umgehen.
(wobei hier die Frage aufkommt, wie du dynamische Strukturen denn statisch bindest ?)

Ich stelle mir die Lösung für ILERPG schon reichlich kompliziert vor. In Java ist das ganze ja durch das SQL-Package gelöst (ähnlich wie ADO/DAO/ODBC auf dem PC).

Trotzdem:
Was ist denn Sinn und Zweck solcher dynamischer SQL's, die eigentlich besser innerhalb des jeweiligen Programmes laufen sollten ?

PS:
Das mit "Kunden_DS = SQL_Ergebnis" kann ja nicht funktionieren, solange nicht der "Select" ein "Select *" ist, und dann brauchst du kein Service-Programm.

[sim]

Also,

das Service Programm wird tatsächlich Prozeduren wie z.Bsp

sql_openstatement(STATEMENT) --> liefert handle
sql_closestatement(...)
sql_execstatement.... etc enthalten

dieses Servicepgm kann ich dann in allen ILE programmen verwenden ohne das ich umständlich mit emb. sql etc hantieren muß. einfach der prozeduren aufrufen, fertig.

Richtig dynamisch im Sinne von irgendeinen SQL aus ner Datei lesen und den ausführen geht natürlich nicht.
Aber immerhin kann ich in meinem jew. Programm mit 3 kurzen Anweisungen die SQLs ausführen. Vorher noch Statement definieren und Ergebnis_ds und es läuft.


Sinn und Zweck:
Arbeitserleichterung, siehe oben

Ok, das mit der Kunden_ds und dem select war im Beispiel falsch. Die Kunden_ds bzw die jeweilige "Ziel_ds" muß natürlich entsprechend definiert sein.

Ach ja, ist es denn nicht so das in einem SQLRPGLE Programm keine Binderverzeichnisse bzw externe Prozeduren bzw Serviceprogramme eingebunden werden können ?

sim

[Fuerchau]

Wer sagt denn sowas ?
CRTSQLRPGI erlaubt die Angabe OBJTYPE(*PGM/*MODULE), was also das spätere CRTPGM mit Binden auf Service-Programme erlaubt.

Auswahl 15 des PDM macht das automatisch.

Wenn du also sowieso feste Strukturen zum Select definieren musst, und nicht tatsächlich dynamische SQL's benötigst (innerhalb eines Moduls), dann ist embedded SQL die bessere Alternative.

Ausserdem, wie siehts aus mit Update/Insert ?

[sim]

Hmm, werd ich mal ausprobieren.

Aber unbestritten ist doch wohl der Punkt der Arbeitserleichterung. Natürlich vorausgesetzt die Performance ist die gleiche kann ich hier mit wenigen Anweisungen
SQL Abfragen ausführen


Updates und Inserts sollten auch kein Problem sein, natürlich mit entsprechenden Prozeduren.


Wie gesagt haben wir bereits eine entsprechende Lösung die allerding nur SELECTs verarbeiten kann. Und verwenden dies bereits in dutzenden Programmen bei gleicher Performance und ohne große Nachteile.

[Fuerchau]

Die Performance ist auch nahezu gleich (CLI ist ca. 10% langsamer).

Trotzdem ist es einfacher und auch schneller in der Entwicklung, direkte SQL's im Programm zu verwenden.

Ich definiere meinen Cursor
declare xx cursor for
select ....
where keyx = :mykeyx ...

Der Vorteil hier sind Parameter, die ich bei dynamischem SQL erst noch zusammensetzen muss. Zeichen in Hochkomma, Dezimal ggf. mit Dezimalpunkt usw.
Parameter kennen das Problem nicht.

Meistens steht man vor einem Problem, wenn ein Zeichen-Parameter selber ein Hochkomma enthält (Suche alle O'Mally), dieses ist nämlich zu verdoppeln !!!

Oder ich erlaube wiederum Parametermarker (SQLBindParm), was die Sache verkompliziert.

Da ich eine Struktur benötige, definiere ich halt die Struktur der Felder, wie ich sie brauche, lesen kann ich dann mittels

fetch cursor into :structname

wobei automatisch das 1. Feld des Selects dem 1. Feld der Struktur zugewiesen wird.

Benötige ich ggf. noch NULL-Flags (wie siehts denn damit bei deinem Service-PGM aus), gebe ich einfach ein NULL-Flag-Array beim Fetch an.

Bin ich sicher, dass ein Select nur einen Satz/Zeile liefert, kann ich mir sogar den Cursor sparen, indem ich direkt den

select f1, f2, ... into :Struct
from ...
where key1 = :key1 ...

ausführe.
Also kein Open, Fetch, Close sondern genau 1 Zugriff.

Bevor ich mich also mit deinen CLI-Schnittstellen beschäftige, habe ich den SQL (den ich ja sowieso benötige) schneller im SEU erfasst, zumal ja da auch noch Syntax-Unterstützung gewährt wird.

Also Arbeitserleichterung sehe ich da überhaupt nicht, eher im Gegenteil !