Re: converting pointer to value

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

Den 2021-03-04 kl. 22:27, skrev Dmitry A. Kazakov:
> On 2021-03-04 20:38, Shark8 wrote:
>> On Thursday, March 4, 2021 at 10:35:01 AM UTC-7, Dmitry A. Kazakov wrote:
>>> On 2021-03-04 17:55, Shark8 wrote:
>>>
>>>>> type SQLPOINTER is private;
>>>> ....
>>>>> private
>>>>> type SQLPOINTER is new System.Storage_Elements.Integer_Address;
>>>>
>>>> And here we have SQLPOINTER, which is private, but which is 
>>>> something of the same representation that Integer_Address has; let's 
>>>> assume that the ADDRESS type is implementation-defined, and a 
>>>> private type.
>>> SQLPOINTER is System.Address.
>>
>> Which is implementation-defined.
> 
> No, it defined this way
> 
>     typedef void * SQLPOINTER;
> 
> so for all purposes it is System.Address.
> 
>> None of that addresses the issue that he asked: "how to get the Pvalue 
>> as an SQLRETURN?"
> 
> OK, then the answer is you don't.
> 
> As the rule QDBC does not overlay different types. There are special 
> pointer values though, like 1 etc. Integer_Address can be used to encode 
> them. They are constants.
> 
> P.S. I think the OP refers to SQLParamData/SQLPutData mechanism. There 

Yes - I am. But the problem at hand was more of Ada nature than handling 
tha ODBC API (eventhough yuo've started med thinking about if I'm doing 
it the right way)

> is no overloading either. It works this way:
> 
>     prepare
>     bind to special "address" value, 1, I believe
> 
>     execute
>     if SQLParamData = need_data then
>        loop
>           SQLPutData (next chunk)
>        end loop;
>     end if;
> 
> I do not think it is worth using, unless the data are so big that they 
> are not in the memory, or read from a stream chunk by chunk etc. Clearly 
> it is a very expensive method. A normal bind would be a better choice 
> for most applications.

Yes. The use case at hand is with data fitting into RAM.
But that might change - hence the PutData way.

But I will reconsider, and contemplate if I really need that.

-- 
Björn