FreeTDS Development Group

["Charles Bearden" <Charles.F.Bearden AT uth.tmc.edu>]

> -----Original Message-----
> From: freetds-bounces AT lists.ibiblio.org [mailto:freetds-
> bounces AT lists.ibiblio.org] On Behalf Of ZIGLIO, Frediano, VF-IT
> >
> > 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).

Here's one rub: I haven't been able to get iODBC to give me a trace.  I
have this in my .odbc.ini file, in addition to my data source
definitions:

[ODBC]
Tracing = 1
TraceFile = /home/whoever/opt/tmp/odbctrace.log
Debugging = 1
DebugFile = /home/whoever/opt/tmp/odbcdebug.log

However, no log file ever shows up there.  The program runs as user
'whoever', and the destination is writable by whoever.  In fact, I also
wrote the freetds log to the same location, and it of course worked.

Chuck