FreeTDS Development Group

["Brian Bruns" <camber AT ais.org>]

> > From: Bill Thompson [mailto:thompbil AT exchange.uk.ml.com]
> > Sent: September 16, 2002 8:34 AM
> > 
> > > 3) The date formats are different - the output format 
> > > excludes the seconds
> > > and milliseconds, which is not acceptable. 
> > 
> > I'm in two minds about how to do this. I think the neatest 
> > way would be to
> > temporarily override the date output format while in function
> > _bcp_exec_out().
> > I can see how to do this from the code in dbinit(), but the trouble is
> > that the context is declared static in dblib.c :
> > 
> > static DBLIBCONTEXT *g_dblib_ctx = NULL;
> > 
> > and I need to reference it from bcp.c ....
> > 
> > Would it be safe to increase the scope of this declaration ?
> 
> Bill, 
> 
> If you "temporarily" override the date conversion string in g_dblib_ctx
> during bcp, won't other connections be affected?  
> 
> dbopen() passes that pointer to tds_connect(), which embeds it in the
> process's TDSSOCKET.  That is how context is passed to tds_convert().
> Instead of touching the global context, I think bcp_init() should modify its
> dbprocess:
> 
> 1. copy the global structure pointed to by g_dblib_ctx.

I think this is really a misuse of what TDSCONEXT is supposed to be. 
There is only one (implicit) dblib context.  And it really breaks down in
ctlib.

> 2. replace TDSLOCINFO.date_fmt in the copy with the right one for bcp.

ctlib has the CS_DATAFMT for specifying conversion stuff, perhaps we need
to be taking notes from them?

> 3. overwrite DBPROCESS.tds_socket->tds_ctx with a pointer to the modified
> copy.  (Perhaps a function like "tds_setcontext()" would be handy, taking a
> new pointer and returning the old one.)
> 4. (proceed as usual)
> 5. bcp_done() should free the local copy and restore the global context.
> 6. dbclose() should free the context pointer if it does not equal the global
> pointer.
> 
> Manipulation of TDSLOCINFO is made more complicated by its design: it
> consists of three char* pointers.  I'd be tempted to make them char[64], and
> use assert() when reading freetds.conf to make sure the language, char_set,
> and date_fmt all fit.  Valid specifications of these fields would never be
> anywhere close to 64 bytes.  ("Char 64, where are you?"?)  Does anyone see a
> problem with that?  

Not sure this is really solving the problem though.  The sybase date
format stuff doesn't appear to even be stored in the locale info, although
I personally believe that is the right place for it.  The big problem is
we have a few different date representations (dblib, bcp, ctlib, ODBC) for
each locale.  So, a single date format for each locale doesn't seem to be
cutting it.

I would propose allowing each CLI to include date formats in the
locales.conf file ('date format' being the default of course) and then
some mechanism to pass this output 'styling' to tds_convert().  The
convert() server function does something very similar so I don't believe
we are out on a limb if we choose this.

Sybase appears to neatly avoid the issue by supporting a limited number of
styles and localizing those according to some internal rules based on
locale.  Kind of hard to tell what they are doing really, but we should be
a bit more flexible if possible.

Brian