From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on ip-172-31-74-118.ec2.internal X-Spam-Level: X-Spam-Status: No, score=-0.9 required=3.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.5-pre1 Path: eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: =?UTF-8?Q?Bj=c3=b6rn_Lundin?= Newsgroups: comp.lang.ada Subject: Re: converting pointer to value Date: Fri, 5 Mar 2021 08:06:27 +0100 Organization: A noiseless patient Spider Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Injection-Date: Fri, 5 Mar 2021 07:06:28 -0000 (UTC) Injection-Info: reader02.eternal-september.org; posting-host="c9e3b2236f724ff4b8eeba0adbb7f865"; logging-data="16815"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/m3N7/smOncesDZmjUNIQ9" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 Cancel-Lock: sha1:sHTKCkAvxQpH4o20yjQrdJ4WSjo= In-Reply-To: Content-Language: en-US Xref: reader02.eternal-september.org comp.lang.ada:61475 List-Id: Den 2021-03-04 kl. 17:50, skrev Dmitry A. Kazakov: > On 2021-03-04 16:59, Björn Lundin wrote: > >> I am trying to implement clob handling towards a database >> using the ODBC binding at > > I do not think GNADE is supported and correct with the changes MS made > to ODBC after the support was dropped. > > There are actually two ODBC interfaces depending on the machine > architecture, 32- and 64-bit. E.g. SQLSETPOSIROW is 16-bit or 64-bit, > SQLLEN is 32- or 64-bit. That was the change MS did to ODBC for a decade > ago, I believe. Yeah, I doubt it i supported - but I find the feature I use working. A colleague did fix the 64bit changes, I should have mentioned that this is Linux on 64bit that I try. It will run on windows 64 bit (which is the same code) and I might port it to Windows 32-bit - but that I have not decided yet. > >> In one call I do the binding of data to a bind variable. >> >>    insert into table A vales (?,?) >> >> where the '?' are my bind variables in the sql. >> >> Now, when data is small I call bindcol via >> >>    Gnu.Db.Sqlcli.Sqlbindparameter >> >> and put the wanted value into the binding. >> >> But with CLOBs, there are too much data, so instead of setting >> the actual data, one is to indicate which column to put the >> data into - at a later time. > > I do not understand this. Binding binds a variable to a prepared > statement. You change the variable before each execution of the statement: hmm, I usually rebind after an execute. I now realize I don't have to. thanks. > > In case of blobs, if the size vary, you have to rebind it with another > size before another statement execution. Unfortunately column size is a > parameter of SQLBindParameter rather than the parameter data. If the > size is same you only change the buffer contents. The buffer itself can > be allocated once for its maximal size. hmm I did not think of that. But - if the clob is big enough - that will not help. But yes - my use case has likely clobs less than a few Mb. 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 the data (which is the problem i want to solve first) loop putDAta exit when put enough data loop final call to ParamData will now indicate SUCCESS. 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) And yes that small size is just me testing. chunks will be in larger sizes when I get it to work. docs* /Björn > -- Björn