[freetds] Function sequence error from Linux => SQL Server 2000

ZIGLIO, Frediano, VF-IT Frediano.Ziglio at vodafone.com
Thu Apr 29 03:26:13 EDT 2004

> 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."
> In src/odbc/odbc.c, you'll find the implementation of SQLPutData().
> 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
> I think it was only implemented recently to support prepared
> (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
> resident ODBC guru Frediano wants to work on it.  Unless Frediano is
> 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
> 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
> to make sure.  

It's using a store procedure.


More information about the FreeTDS mailing list