FreeTDS Development Group

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

> From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> Sent: June 5, 2002 12:16 PM

> > My only complaint, if I may, is that the default default 
> default format,
> > before locales and/or customization, should emulate the 
> vendors' format,
> > which is "Jun 5 2002 10:15AM", no seconds or milliseconds 
> (and only one
> > space between the month and the day, regardless of the 
> number of digits in
> > the day).  I think applications will break otherwise.  
> 
> OK, I give in. Like I said before, I only tried to mimic the 
> behaviour of
> Sybase dbconvert() in my environment. It's clear that the 
> truth is more
> complicated than I thought...
> I can do the changes easily, but I'll have to rework ny bcp 
> code to get
> the full date string another way (using dbdatecrack() perhaps). Let me
> work on it...

Bill, I don't want to make work for you, and I don't know that your
conversion code has to be reworked.  *Something* has to be reworked,
probably the ct-lib code that still relies on old tds-level behavior.
Please don't pull apart what you've done unless you're sure the ct-lib code
is right.  If our dbconvert exactly mimics Sybase's implementation, then
maybe all we have to do is remediate ct-lib.  

I'm relying of course on your assertion that dbconvert and friends now
precisely conform.  I don't have a handy way to test db-lib functionality,
so I started with the easiest tool.  

I'm sorry if I gave the impression that what you did was in error; I only
meant to say the ct-lib effect is broken, so far.  

> destlen -2 is in my sybase manuals, so I copied it.
> 
> dbbind calls dbconvert. I also amended dbbind to use the -2 and -1
> destlen's where appropriate.
> 
> The caller can know where the conversion ends, because the return code
> from dbconvert gives the valid length. I've tried this with 
> Sybases dblib,

I see.  Thank you.  I missed the return code.  

> sqsh seems to work on the length of the converted string. If 
> I don't blank
> pad it, it adjusts the display accordingly. Hmmmm.

I'm guessing that something somewhere sees a conversion to varchar, and
assumes the converted data will be as long as the longest varchar.  Until
TDS 7.0, the answer to that question was 30; now it's 255.  One problem with
that theory is that my testing was done with TDS 5.0....

> I agree that we will have to take this forward so that we 
> don't break any
> current applications, as those apps may have been built around the way
> that FreeTDS currently behaves...

I doubt we have to emulate our own bugs.  Sybase's, maybe, but if any code
relies on a FreeTDS bug, we'll just do what any vendor would do: tell 'em to
upgrade or keep their old buggy version. 

 
> I also think I'm gonna have to build the ultimate data conversion test
> program that can be linked in with FreeTDS or Sybase. That 
> way we may get
> to the bottom of it all. Let me work on that as well...

Oooh, that sounds good.  Namespaces would make it easier, of course....  An
any-to-any matrix test would be very good advertising, too, when it all
works.  

My present narrow goal is to see sqsh behave exactly the same way regardless
of which libary we use.  I figure that will flush out a few things, and make
the "complicated truth" a little easier to understand.  

I'm also looking forward to freebcp.  I think it would be fun if it dealt
with stdin, if it doesn't already.  I think 

        perl -S foo bar.dat | freebcp foodb..bartable in -U sa -P -c 

is a powerful construct.  

Regards, 

--jkl