Re: What is the Buffer Limit for SQLPutData?

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Michael Thomas [Microsoft] (mithomas_at_online.microsoft.com)
Date: 11/18/04 

Date: Thu, 18 Nov 2004 10:15:53 -0800

Microsoft ODBC3.0 Programmer's Rerence, Volume1, and SDK Guide.
This is a must have if you´re programming ODBC apps.

If the memory allocation returned a valid pointer it likely succeeded.
Let's not worry about that right now.

The data size might be limited by the database driver though. Then you need
to "junk" the data using multiple SqlGetData/SqlPutData calls.
This is described in detail in the above manual as well.

You can also find this information online on http://msdn.microsoft.com :

SQLGetData
SQLGetData is used to retrieve result set data without binding column
values. SQLGetData can be called successively on the same column to retrieve
large amounts of data from a column with a text, ntext, or image data type.

"Al Koch" <AlKoch@MyRealBox.com> wrote in message
news:#0zub7PzEHA.2200@TK2MSFTNGP09.phx.gbl...
> Hi Michael,
>
> Is there ODBC documentation you can point me to that discusses how SQLINT
is
> the controlling factor here? How would someone know this (if they didn't
> get some helpful input as you have supplied!)?
>
> Also, can you explain how I can "verify that the memory allocation
> succeeded"?
>
> I'm not sure if the problem is on the data write or read back. All I can
> verify (at least all I know how to verify) is that the 3MB of binary data
> read back is not the same as the data that was written out. Is there a
way
> to deternine if the "BAADF00D" is being inserted on the way out or back
in?
>
> Thanks for your help with this.
>
> Al
>
> "Michael Thomas [Microsoft]" <mithomas@online.microsoft.com> wrote in
> message news:OUDIpcBzEHA.1860@TK2MSFTNGP15.phx.gbl...
> > Since it's not explicitly specified it should be 2147483647
(0x7FFFFFFF),
> > the maxumum positive value for SQLINT
> >
> > Please verify that the memory allocation succeeded and that the source
> data
> > has been written correctly.
> >
> > Michael
>
>