FreeTDS Development Group

["ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>]

> 
> On Wed, 28 Apr 2004, "James K. Lowden" 
> <jklowden AT schemamania.org> wrote:
> > 
> > The other possibility -- and where we'd be stuck (for now) 
> if I'm right
> > -- is that 8000 bytes might be a real limit.  I think to support
> > inserting ntext data longer than that, we'd have to support the ODBC
> > equivalent of dbwritetext/dbmoretext.  
> 
> As they say in Sweden, "Ja, just det."
> 
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/acdata/
ac_8_qd_13_8orl.asp
>
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht
m/odbcsqlputdata.asp
> 
> In src/odbc/odbc.c, you'll find the implementation of SQLPutData().
This
> is the function ODBC specifies for sending more than 8000 bytes of
> text/ntext data.  I'm not sure it's ever been used in the way you want
to;
> I think it was only implemented recently to support prepared
statements
> (dynamic SQL).  
>

>From log client try to send VARCHAR. The problem is that mssql support
varchar fields are limited to 8000 characters however we send a
character of 8196... We have two problems here
- client should use TEXT (SQL_LONGVARCHAR speaking ODBC)
- FreeTDS should truncate data !!!
It would be fine to have a iODBC dump just to check if client is really
asking to insert VARCHAR (and not TEXT).

> I don't know just exactly what shape SQLPutData() is in, or whether
our
> resident ODBC guru Frediano wants to work on it.  Unless Frediano is
much
> further along with this than I think he is, there's no quick fix.  
>  

SQLPutData is a little broken (you can see this from putdata test...)

> 
> The problem sure seems to be in that vicinity.  Of course, we don't
know
> exactly how the driver's being called, whether the caller realizes the
> data exceed 8000 bytes and calls a (presumably) broken SQLPutData(),
or if
> it's just forming a giant INSERT statement (which, actually, I think,
> would work fine).  You could plop in a few logging statements of your
own
> to make sure.  
> 

It's using a store procedure.

freddy77