cancel
Showing results for 
Search instead for 
Did you mean: 

Confusion on LONG data type support from SQLDBC

Former Member
0 Kudos

Hi All,

Like we know MaxDB 7.6.3 onwards is not going to support CLOB/BLOB and we have to use data types LONG BYTE/LON ASCII etc.

What confuses me though is the content of SQLDBC_C.h file present with the community edition of MaxDB 7.6.3, mainly functions like:

SQLDBC_DLLEXPORT SQLDBC_Retcode SQLDBC_LOB_close(SQLDBC_LOB* hdl);

SQLDBC_DLLEXPORT SQLDBC_Retcode SQLDBC_LOB_putData(SQLDBC_LOB* hdl, void *paramAddr, SQLDBC_Length *paramLengthIndicator);

SQLDBC_DLLEXPORT void SQLDBC_LOB_delete_SQLDBC_LOB(SQLDBC_LOB *lob);

etc.....

Are these functions present to support LONG types ?? Also one more thing i would highly appreciate is, if someone can point me to some example programs which handle the LONG data types.

A working program with things like insert and select and data reading for the LONG would definitely help to clear most of the doubts in my mind.

Regards

Raja

Accepted Solutions (1)

Accepted Solutions (1)

lbreddemann
Active Contributor
0 Kudos

> Like we know MaxDB 7.6.3 onwards is not going to support CLOB/BLOB and we have to use data types LONG BYTE/LON ASCII etc.

Hi Raja,

that's in fact not true.

As already discussed in on of your other questions thread, the commands to create and modify LONG and LONG RAW columns are going to be replaced by the CLOB/LOB semantics.

You can still use them for the next major versions but somewhere in the future you'll have to move to CLOB/LOB.

Concerning the programming of LONGS - you can just use them as any other "normal" column of a table. You just have to make sure that your client structure can actually take the data stored in the LONG field.

If this is given you simply fetch the data as you would fetch any record.

For (C)LOBS you may have more options, like just accessing a specific part of the LOB (and not all the data).

regards,

Lars

Former Member
0 Kudos

Hi Lars,

I again return back to this topic as i have just started investigating this part and am currently trying to write some example programs to improve my confidence in handling the LONG data type.

So, one question is: Since you say i can handle LONG data type just like any other data type at least in 7.6.3 and anyway blob/clob data are not supported in this version. Then, what is the purpose/use of these LOB specific functions provided in the SQLDBC_C.h file in the 7.6.3 version ?

SQLDBC_DLLEXPORT SQLDBC_Retcode SQLDBC_LOB_close(SQLDBC_LOB* hdl);

SQLDBC_DLLEXPORT SQLDBC_Retcode SQLDBC_LOB_putData(SQLDBC_LOB* hdl, void *paramAddr, SQLDBC_Length *paramLengthIndicator);

SQLDBC_DLLEXPORT void SQLDBC_LOB_delete_SQLDBC_LOB(SQLDBC_LOB *lob);

I'm little confused, please help.

Regards

Raja

Former Member
0 Kudos

Hi,

Also one more question is if i am trying to bind a column of a long data type say from a result set to my application, then what memory size should i allocate for my local variable which will hold the data from long variable.

If i go by the section 'Memory Requirements of a Column Value According to Data Type' the space requirement is 41 bytes. Is that all i need to allocate for the local variable?

Regards

Raja

alexander_schroeder
Participant
0 Kudos

Regarding the memory size:

For buffer-based host variables: The indicator will tell after the operation how much data in bytes was available was before the operation. One can use getObject afterwards to get the rest.

SQLDBC_LOB is an object. No size is needed, but the getLength method will tell you the size of the LOB/LONG.

Regards

Alexander

The 41 bytes is the internal length in the handle transmission from SAP MaxDB server to client, and has no use at all here ...

Former Member
0 Kudos

Suppose I want to use the option u2018au2019:

a) use a normal ASCII/BINARY/UCS2/UTF8 host variable

This is advisable if the size of the LOB is small, and known, and the data is somehow read into the application and present anyway.

Please let me know how to achieve this, my confusion is mainly with regard to the following question:

i. Can I bind the LONG column and still do insert and update statements? If yes, then while binding what length and address should I mention for SQLDBC_PreparedStatement_bindParameter function.

ii. Once I have bound the LONG columns, can I simply do a memcpy of the data to the address location which is bound? I tried to do the same thing with SQLDBC_PreparedStatement_putData, but got a u2018Segmentation Faultu2019. So, the question is how should i copy the data to the bound columns.

Regards

Raja

Answers (1)

Answers (1)

alexander_schroeder
Participant
0 Kudos

Hello,

the LONG data type was just renamed in versions >7.6 as

- CLOB/BLOB are the standard names

- people confused the LONG type with some variant of integer numbers

Sorry that we created confusion in attempt to remove some.

However, when processing LOB data in SQLDBC, one has several

options:

a) use a normal ASCII/BINARY/UCS2/UTF8 host variable

This is advisable if the size of the LOB is small, and known, and the data is somehow read into the application and present anyway.

b) use the DATA AT EXECUTE facilities

This is a callback mechanism which is similar to the ODBC way of supporting the use of longer values that don't fit into the application. I would advise this only if you port an ODBC application that already uses this - otherwise it can be quite complicated.

c) use the SQLDBC_LOB host type

This will get you an handle on the LOB after executing a INSERT/UPDATE command for writing data, and a handle

on the LOB after SELECT for reading data.

a) and c) can be easily mixed, b) has influecnce on the mechanics of statement execution that prohibit the use with c) together.

Hope this helps a little

Alexander

Edited by: Alexander Schroeder on Sep 23, 2008 7:00 AM