SYSTOOLS.JSON2BSON

[Fuerchau]

V7R1 ist da schon wieder besser:
http://www-01.ibm.com/support/knowle...st.htm?lang=de

Du kannst Variablen auch dynamisch per Pointer bearbeiten und anlegen, siehe hierzu %alloc(), %dealloc() um nicht permanent den maximal möglichen Speicher vorzuhalten.

[Fuerchau]

Und hier gibt's auch ein paar Beispiele:
http://www.ibmsystemsmag.com/ibmi/de...CLOBs-and-RPG/
Vom Datum her kann man mal sehen wie lange es das schon gibt.

[Rainer Ross]

Das API QtmhRdStin hat folgende Parameter

dcl-pr readstdin    extproc('QtmhRdStin'); 
        tmhdata     pointer        value;  
        tmhdatlen   int(10)        const;  
        tmhavail    int(10)        const;  
        tmerror     like(d#apierr) const;  
end-pr; 

Die Länge der Daten ist int(10), damit können sie bis max 2.147.483.647 Byte gross sein. Ich benutze das API, um z.B. PDF's auf den Server hochzuladen.

Ein CLOB oder BLOB-Feld kann maximal 16MB gross sein. Das sollte auch ausreichen.
Wie Fürchau schon richtig gesagt hat, kannst Du über Locator arbeiten, oder es wie folgt definieren

dcl-s   s#file      sqltype(CLOB_FILE);    
dcl-s   s#clob      sqltype(CLOB:16000000);
dcl-s   s#loc       sqltype(CLOB_Locator); 

Viele Grüße

Rainer

[B.Hauser]

LOB-Variablen (z.B. SQLTYPE(CLOB: 10000000) können nur bis 16MB definiert werden.
LOB Locators (z.B. SQLTYPE(CLOB) sind (versteckte) Pointer die auf ein bis 2 GB großes LOB zeigen.
Auf LOB-Locators kann mit native RPG-OpCodes und Built-In-Functions nicht zugegriffen werden, aber mit embedded SQL können LOB-Locators mit SQL-Funktionen wie alphanumerische Felder behandelt werden, z.B. können LOBs mit LOCATE durchsucht, oder Teile mit SUBSTR herausgebrochen werden. Die Verarbeitung von LOB Locators muss unter Commitment Control erfolgen, da der Locator wieder freigegeben werden muss. Die Freigabe erfolgt über COMMIT / ROLLBACK oder FREE Locator.
File-Referenz-Variablen (z.B. SQLTYPE(CLOB_FILE)) sind wie Locators versteckte Pointer, die jedoch auf eine Datei im IFS oder eine Teil-Datei zeigen. Auf diese File-Referenz-Variablen kann man mit SQL-Funktionen wie auf alphanumerische Felder zugreifen. Im Gegensatz zu den Locators muss die Verarbeitung von File-Referenz-Variablen nicht zwangsläufig unter COMMIT erfolgen.

Birgitta
Eine Anmerkung noch: Wenn mit LOB-Locators gearbeitet wird, muss die Verarbeitung unter Commitment Control erfolgen.

[rischer]

Das API QtmhRdStin hat folgende Parameter

dcl-pr readstdin    extproc('QtmhRdStin'); 
        tmhdata     pointer        value;  
        tmhdatlen   int(10)        const;  
        tmhavail    int(10)        const;  
        tmerror     like(d#apierr) const;  
end-pr; 

Die Länge der Daten ist int(10), damit können sie bis max 2.147.483.647 Byte gross sein. Ich benutze das API, um z.B. PDF's auf den Server hochzuladen.

Ein CLOB oder BLOB-Feld kann maximal 16MB gross sein. Das sollte auch ausreichen.
Wie Fürchau schon richtig gesagt hat, kannst Du über Locator arbeiten, oder es wie folgt definieren

dcl-s   s#file      sqltype(CLOB_FILE);    
dcl-s   s#clob      sqltype(CLOB:16000000);
dcl-s   s#loc       sqltype(CLOB_Locator); 

Viele Grüße

Rainer

Ich habe ja kein Problem mit QtmhRdStin (das ich seit Jahren verwende) sondern mit der Tatsache, daß ich den von QtmhRdStin erhaltenen alpanumerischen String via embedded SQL in meiner Datenbank speichern will. Und da ist bei standard-embedded bei ca. 32700 Zeichen schluß.

[Fuerchau]

Wie du oben siehst, ist das bei SQLTYPE(CLOB:16000000) oder SQLTYPE(BLOB:16000000) nicht der Fall.
Es wird eine Struktur erstellt, in der du deine Daten und Länge abgeben kannst und als CLOB/BLOB an SQL geben oder von SQL lesen kannst.

Alternativ eben LOBLOCATOR die dann per SUBSTR o.ä. angesprochen werden können.
Dann kannst du eben 2GB per SQL-"set " und SUBSTR die Teilstrings aneinander ketten oder auslesen.

[rischer]

Wie du oben siehst, ist das bei SQLTYPE(CLOB:16000000) oder SQLTYPE(BLOB:16000000) nicht der Fall.
Es wird eine Struktur erstellt, in der du deine Daten und Länge abgeben kannst und als CLOB/BLOB an SQL geben oder von SQL lesen kannst.

Alternativ eben LOBLOCATOR die dann per SUBSTR o.ä. angesprochen werden können.
Dann kannst du eben 2GB per SQL-"set " und SUBSTR die Teilstrings aneinander ketten oder auslesen.

Ahhh....verstehe....da bin ich jetzt echt auf der Leitung gestanden....dank...

[Fuerchau]

Die 32K galten bis V5, ab V6 gehen eben 16MB direkt.

[rischer]

Und hier gibt's auch ein paar Beispiele:
http://www.ibmsystemsmag.com/ibmi/de...CLOBs-and-RPG/
Vom Datum her kann man mal sehen wie lange es das schon gibt.

Schon, aber in diesen Beispielen wird doch nur demonstriert wie mit diesen Objekttypen umgegangen wird und bei embedded wird auch nicht die magische Grenze von 32700 überschritten - oder habe ich da was falsch verstanden?