FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

> From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
> Sent: May 6, 2003 8:11 AM
> Il mar, 2003-05-06 alle 13:20, Arnar Birgisson ha scritto:
> > 
> > > 1.  Copy tds_set_column_type to a new function, say, 
> > > tds_set_param_type
> > > 2.  Remove tds_get_cardinal_type() from 
> tds_set_param_type (just use
> > > 'type')
> > > 3.  Modify param_info_alloc to call tds_set_param_type()
> > 
> > I did exactly this. After making this small change to the client (in
> > this case php):
> > -#define SQLVARCHAR SYBVARCHAR
> > +#define SQLVARCHAR XSYBVARCHAR
> 
> This patch lead to portability problem...
> 
> > this worked perfectly. I haven't tried it extensively, but I ran a
> > procedure which silently accepted a varchar field with well over 400
> > characters.
> 
> IMHO is not so good. Or we remove the cardinal type from
> tds_set_column_type (and perhaps column_type from TDSCOLINFO) 
> and change
> all other code to handle all types or we use tds_set_column_type for
> params...

(Arnar, thank you for the patch.  I don't know whether we'll use it
verbatim, but obviously at the very least it's a starting point.)  

Freddy, what Arnar did was demonstrate that tds_get_cardinal_type() was in
the way.  I didn't want to suggest he change tds_set_column_type(), because
I don't know the ramifications.  

We're both scratching our heads, istm, wondering if "cardinal type" isn't a
bogus concept.  That's the crux.  Do we need it, and, if so, why?  

I suspect we need it, because there are more server types than client types.
No application expects "XSYBVARCHAR" when asking for a column's type.  The
conversion has to be done, implicitly, in libtds: on receipt of XSYBVARCHAR,
we tell the client it's a SYBVARCHAR.  On sending to a TDS 7.0+ server,
SYBVARCHAR becomes XSYBVARCHAR.  Nes pas?  

The lesson, apparently, is to use "cardinal type" when we make
representations to the client only.  The error in tds_set_column_type() was
to go the opposite way: we knew we had XSYBVARCHAR, but told the server it
was an old-fashioned SYBVARCHAR.  

Next step would be to analyze inbound and outbound uses of
tds_set_column_type().  I'm betting it's 100% inbound except for sending
parameters.  If so, then I think we need Arnar's patch or something like it,
so as not to send bogus types to the server.  

The only other place I can think of that sends column types is BCP.  bpc.c
must do something different, because we send long varchar data successfully.


Regards, 

--jkl


The information contained in this transmission may contain privileged and
confidential information and is intended only for the use of the person(s)
named above.  If you are not the intended recipient, or an employee or agent
responsible for delivering this message to the intended recipient, any
review, dissemination, distribution or duplication of this communication is
strictly prohibited. If you are not the intended recipient, please contact
the sender immediately by reply e-mail and destroy all copies of the
original message. Please note that we do not accept account orders and/or
instructions by e-mail, and therefore will not be responsible for carrying
out such orders and/or instructions.