Re: converting pointer to value

["Björn Lundin" <b.f.lundin@gmail.com>]

Den 2021-03-05 kl. 08:44, skrev Dmitry A. Kazakov:
> On 2021-03-05 08:06, Björn Lundin wrote:
> 
>> Anyway, some docs* I found describes Clob handling as
> 
>> use bind to bind nothing to the col - but tag it
>> execute (will then return NEED_MORE_DATA)
>> ParamData will return NEED_MORE_DATA and indicate what col that needs 
> 
> Yes, it returns in its buffer address + offset calculated as if 
> parameters were an array. Here address is 1, if I remember correctly.
> 
> But you can just ignore that stuff as you know the column you write 
> already. 

I can't. This is code fitting as glue between ODBC binding and 
application code.
Meaning some of my colleagues could define a clob as any column

>There is only one blob.

and actually, that is not ceratain.
Some colleagues actually defined a table containing two clobs.
And there really is not limit (more than practical use)

If other parameters are bound normally
> or literals you just call PutData with the first chunk ignoring anything 
>   but the return code of ParamData.

yes, and that is how I got it to work while trying and testing
But it won't hold in the end. I got to get the column(s) back (or 
rethink the use of the API)

>>
>> And I got that part to work to some extent. (if I putData in chunks of 
>> 10 bytes and I said size= 100. But not if size = 104. Likely an error 
>> on my part)
> 
> Did you specify 104 as the total size in BindParameter?

Yes. And I 10 chunks of 10 bytes + 1 chunk of 4 bytes.
I tried null-terminate the last chunk, both by j
* just by appending an ASCI.NUL (5 bytes for last chunk - 105 bytes in 
total)
* replacing last byte in last chunk with ASCII.NUL - 104 bytes in total

No go still


> It will be awfully slow, I guess.
Likely, but I did not measure anything yet.
I think the usecase for it will be uncommon, so I might tolerate 
'somewhat' slow execution.


-- 
Björn