Skip to Content.
Sympa Menu

freetds - Re: [freetds] locales.conf

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Andrew J. Hutson" <andrewh AT advfn.com>
  • To: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • Cc: FreeTDS Users <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] locales.conf
  • Date: Fri, 13 Feb 2004 13:34:29 -0000

It appears that I am not getting the same as you:

2004-02-13 13:32:36.377053 inside cs_convert() srctype = 61 (8) desttype =
47 (257)
2004-02-13 13:32:36.377078 inside cs_convert() calling tds_convert
2004-02-13 13:32:36.377124 inside cs_convert() tds_convert returned 24

This is what was returned:
Fri Feb 13 13:32:36 2004

...which has length 24. Seems that the problem does lie with FreeTDS after
all.

----- Original Message -----
From: Thompson, Bill D (London)
To: 'Andrew J. Hutson'
Sent: Friday, February 13, 2004 12:10 PM
Subject: RE: [freetds] locales.conf


Andrew,

If you were to set up a very simple test harness, and capture a FreeTDS dump
(with the $TDSDUMP env variable),
we ought to be able to rule Freetds in or out of the equation.

capturing a dump from sqsh, when I did a "select getdate()", I got in the
dump:

2004-02-13 12:10:11.395140 inside cs_convert() srctype = 61 (8) desttype =
47 (20)
2004-02-13 12:10:11.395748 inside cs_convert() calling tds_convert
2004-02-13 12:10:11.396741 inside cs_convert() tds_convert returned 19

Some debug from the conversion routines.
when converting the date to a string, tds_convert returned the length of the
resulting string (19), which conforms to the output:

Feb 13 2004 12:10PM

If you get the same output, then your version of freetds is doing the same
as mine...and something *else* is affecting the date format afterwards...

If you got "tds_convert returned 24" - then we'd know freetds was producing
the erroneous date format....

Not *much* help I know, but it would help to rule freetds in or out of the
problem...

Bill

> -----Original Message-----
> From: Andrew J. Hutson [SMTP:andrewh AT advfn.com]
> Sent: Friday, February 13, 2004 11:51 AM
> To: Thompson, Bill D (London); 'FreeTDS Development Group'
> Subject: Re: [freetds] locales.conf
>
> Surely I'm not the only person ever to try and run PHP 4.3.3 with FreeTDS
> on
> a Debian platform and make Sybase date queries?!
>
> I don't know how PHP and libct1 interact, but how would PHP be forcing
> libct1 into using a certain date format? And why? And how do I stop it?
> This
> seems such a trivial issue which is blocking development of other
> dependants!
>
> Any other ideas?
>
> ----- Original Message -----
> From: Thompson, Bill D (London)
> To: 'Andrew J. Hutson' ; 'FreeTDS Development Group'
> Sent: Friday, February 13, 2004 10:07 AM
> Subject: RE: [freetds] locales.conf
>
>
> Hi Andrew,
>
> Just a quick observation, for what it's worth....
> >From what I know of FreeTDS date->string conversions
>
> "Tue May 14 08:58:00 2002"
>
> doesn't look like any date format that our conversion routines would
> produce
> by default or otherwise. I've never seen that as a date format anywhere...
>
> I'm deducing from your mention of "libct1 0.61.5" that PHP is configured
> --with-sybase-ct , i.e. it is using the ct-library API
>
> The default date format in FreeTDS ct-lib is "%b %e %Y %I:%M%p" - "May 14
> 2002 8:58AM"
>
> AFAICT the only way that can be overridden within FreeTDS is by the
> locales
> file , which should be in :
>
> <wherever FreeTDS is installed>/etc/locales.conf
>
> I'd start to suspect PHP somehow...
>
> Bill
>
> > -----Original Message-----
> > From: Andrew J. Hutson [SMTP:andrewh AT advfn.com]
> > Sent: Friday, February 13, 2004 9:26 AM
> > To: Lowden, James K
> > Cc: FreeTDS Users
> > Subject: Re: [freetds] locales.conf
> >
> > > > From: Andrew J. Hutson [mailto:andrewh AT advfn.com]
> > > > Sent: February 12, 2004 10:19 AM
> > > >
> > > > Have just upgraded PHP to 4.3.3, and consequently had to
> > > > change from freetds0 0.53-7 to libct1 0.61-5. The upgrade has
> > > > worked fine, apart from the fact that the date format
> > > > returned from Sybase queries has changed. It used be in the
> > > > following format (example):
> > > >
> > > > May 14 2002 8:58AM
> > > >
> > > > but is now in this format:
> > > >
> > > > Tue May 14 08:58:00 2002
> > > >
> > > > I have tried putting the following in /etc/freetds/locales.conf:
> > > >
> > > > [default]
> > > > date format = %b %d %Y %I:%M%p
> > > >
> > > > [en_US]
> > > > date format = %b %d %Y %I:%M%p
> > > > language = us_english
> > > > char set = iso_1
> > > >
> > > > But nothing changes. It does appear to be paying any
> > > > attention to the locales.conf file.
> > >
> > > The default prefix changed after 0.53. Unless you altered configure's
> > default, you installed into /usr/local, and you need to edit
> > /usr/local/etc/locales.conf. You > can double check which file is being
> > consulted with TDSDUMPCONFIG.
> >
> > There is no /usr/local/etc directory. I tried making one and copying the
> > config into it, but it made no difference. I didn't compile it from
> > source,
> > as it was a Debian package, so it did everything itself. TDSDUMPCONFIG
> > doesn't seem to say anything about locales.conf, however it does
> indicate
> > that it is reading from /etc/freetds/ rather than /usr/local/etc/. I
> have
> > pasted it's output below:
> >
> > Starting log file with debug level 99.
> > 2004-02-12 23:59:01.930187 Attempting to read conf files.
> > 2004-02-12 23:59:01.930243 ...$FREETDSCONF not set. Trying $HOME.
> > 2004-02-12 23:59:01.930400 Found conf file '/etc/freetds/freetds.conf'
> > (default). Reading section 'DB1'.
> > 2004-02-12 23:59:01.930446 Looking for section global.
> > 2004-02-12 23:59:01.930541 ... Found section global.
> > 2004-02-12 23:59:01.930575 Got a match.
> > 2004-02-12 23:59:01.930608 option = 'tds version' value = '5.0'.
> > 2004-02-12 23:59:01.930648 option = 'initial block size' value = '512'.
> > 2004-02-12 23:59:01.930688 option = 'swap broken dates' value = 'no'.
> > 2004-02-12 23:59:01.930722 no is a 'no/off/false'.
> > 2004-02-12 23:59:01.930759 option = 'swap broken money' value = 'no'.
> > 2004-02-12 23:59:01.930792 no is a 'no/off/false'.
> > 2004-02-12 23:59:01.930832 option = 'try server login' value = 'yes'.
> > 2004-02-12 23:59:01.930865 yes is a 'yes/on/true'.
> > 2004-02-12 23:59:01.930900 option = 'try domain login' value = 'no'.
> > 2004-02-12 23:59:01.930933 no is a 'no/off/false'.
> > 2004-02-12 23:59:01.930975 option = 'cross domain login' value = 'no'.
> > 2004-02-12 23:59:01.931008 no is a 'no/off/false'.
> > 2004-02-12 23:59:01.931052 ... Found section db1.
> > 2004-02-12 23:59:01.931092 ... Found section db1_back.
> > 2004-02-12 23:59:01.931131 ... Found section db1_mon.
> > 2004-02-12 23:59:01.931169 ... Found section db2.
> > 2004-02-12 23:59:01.931209 ... Found section db2_back.
> > 2004-02-12 23:59:01.931248 ... Found section db2_mon.
> > 2004-02-12 23:59:01.931286 ... Found section db3.
> > 2004-02-12 23:59:01.931326 ... Found section db3_back.
> > 2004-02-12 23:59:01.931365 ... Found section db3_mon.
> > 2004-02-12 23:59:01.931404 ... Found section db4.
> > 2004-02-12 23:59:01.931443 ... Found section db4_back.
> > 2004-02-12 23:59:01.931482 ... Found section db4_mon.
> > 2004-02-12 23:59:01.931521 ... Found section sybase.
> > 2004-02-12 23:59:01.931561 ... Found section sybase_back.
> > 2004-02-12 23:59:01.931601 ... Found section sybase_mon.
> > 2004-02-12 23:59:01.931641 ... Found section database1.
> > 2004-02-12 23:59:01.931680 ... Found section db8.
> > 2004-02-12 23:59:01.931724 Looking for section db1.
> > 2004-02-12 23:59:01.931794 ... Found section global.
> > 2004-02-12 23:59:01.931874 ... Found section db1.
> > 2004-02-12 23:59:01.931905 Got a match.
> > 2004-02-12 23:59:01.931935 option = 'host' value = 'db1'.
> > 2004-02-12 23:59:01.931969 Found host entry db1.
> > 2004-02-12 23:59:01.932466 IP addr is 10.0.2.1.
> > 2004-02-12 23:59:01.932505 option = 'port' value = '4100'.
> > 2004-02-12 23:59:01.932544 ... Found section db1_back.
> > 2004-02-12 23:59:01.932584 ... Found section db1_mon.
> > 2004-02-12 23:59:01.932623 ... Found section db2.
> > 2004-02-12 23:59:01.932662 ... Found section db2_back.
> > 2004-02-12 23:59:01.932702 ... Found section db2_mon.
> > 2004-02-12 23:59:01.932740 ... Found section db3.
> > 2004-02-12 23:59:01.932780 ... Found section db3_back.
> > 2004-02-12 23:59:01.932819 ... Found section db3_mon.
> > 2004-02-12 23:59:01.932858 ... Found section db4.
> > 2004-02-12 23:59:01.932897 ... Found section db4_back.
> > 2004-02-12 23:59:01.932936 ... Found section db4_mon.
> > 2004-02-12 23:59:01.932976 ... Found section sybase.
> > 2004-02-12 23:59:01.933016 ... Found section sybase_back.
> > 2004-02-12 23:59:01.933055 ... Found section sybase_mon.
> > 2004-02-12 23:59:01.933095 ... Found section database1.
> > 2004-02-12 23:59:01.933134 ... Found section db8.
> > 2004-02-12 23:59:01.933173 ...Success.
> > 2004-02-12 23:59:01.933213 Setting 'dump_file' to '/temp/freetds.log'
> from
> > $TDSDUMP.
> >
> > I found an article from someone else who had this problem, but it seems
> > there was never a resolution. Is this a common problem? What would you
> > suggest? Using the newer version? Will this actually help? I am
> concerned
> > that there might be problems with it if it hasn't been packaged with
> > Debian
> > yet...
> >
> > >
> > > We never issued a "0.61-5" release; we had a 0.61.x and a month ago
> > issued
> > 0.62.1.
> >
> > It might have been a good idea for me to mention that it's a Debian
> > system:
> > http://packages.debian.org/testing/libs/libct1 This shows 0.61-5 - the
> > same
> > version is in unstable, so it seems 0.62.1 hasn't been put into Debian
> > yet.
> >
> > >
> > > HTH.
> > >
> > > --jkl
> >
> > _______________________________________________
> > FreeTDS mailing list
> > FreeTDS AT lists.ibiblio.org
> > http://lists.ibiblio.org/mailman/listinfo/freetds
>
> ==========================================================================
> ==
> ==
>
> If you are not an intended recipient of this e-mail, please notify
> the sender, delete it and do not read, act upon, print, disclose,
> copy, retain or redistribute it.
>
> Click here for important additional terms relating to this e-mail.
> http://www.ml.com/email_terms/
>
> ==========================================================================
> ==
> ==
>

============================================================================
==

If you are not an intended recipient of this e-mail, please notify
the sender, delete it and do not read, act upon, print, disclose,
copy, retain or redistribute it.

Click here for important additional terms relating to this e-mail.
<http://www.ml.com/email_terms/>

============================================================================
==





Archive powered by MHonArc 2.6.24.

Top of Page