Michael Peppler
Sybase Consulting
Sybase on Linux
Install Guide for Sybase on Linux
General Sybase Resources
General Perl Resources
BCP Tool
Bug Tracker
Mailing List Archive
Downloads Directory
Sybase on Linux FAQ
Sybperl FAQ
Michael Peppler's resume

sybperl-l Archive

Up    Prev    Next    

From: "John A dot Lewis" <John_Lewis-SC2065 at email dot mot dot com>
Subject: Re: Sybperl Datetime and Open Client Version
Date: Oct 21 1998 10:56PM

Well, I found the "bug fix" which is causing my problem.  This is from
the cover letter for EBF 8050:

   SwrID  BugID  Description
   -----  -----  -------------------------------------------------------
    7042  122433  COMNLIB: Default conversion format from a char type to
                  date type has been changed from DATES_LONG to
                  DATES_SHORT ( doesn't have secs and milli-secs)

Apparently this was done as part of some ANSI compliance issue.

I have been trying to use cs_dt_info to correct the default, but it
doesn't seem to have any effect.  Here is the test program I am using:


   use Sybase::CTlib;


   $dbh = Sybase::CTlib->ct_connect("user","password","server");

   @data = $dbh->ct_sql("select getdate()");

   foreach $row (@data)
     print $$row[0]."\n";

Am I doing something wrong here, it is cs_dt_info not working properly? 
I have tried several of the other formats and I still always get the
standard default.

John Lewis

Michael Peppler wrote:
> One way is to include a full convert() call in the SQL, something like
> convert(varchar, date, 109) (not sure if 109 is the right format,
> though).
> Another way is to set $dbh->{UseDateTime} on and retrieve the date in
> native format - which will let you have the full precision.
> A third possibility would be to play with the locale files, although I
> haven't
> tried this at all.
> Michael
> John A. Lewis wrote:
> >
> > I have quite a few Sybperl scripts that work with datetime columns.
> > These scripts all break if I use any version of Open Client newer than
> > 10.0.4 EBF 6847.  The reason is that the precision on the string version
> > of the datetime has changed.  In the older versions of Open Client, I
> > get values like 'Oct 19 1998  3:54:03:446PM', which I can then use in
> > the where clause of a SQL statement and get an exact match since the
> > milliseconds are included.  In the newer versions of Open Client, I only
> > get 'Oct 19 1998  3:54PM', which no longer has enough precision for an
> > exact match.  Anyone know why this is happening and how I can fix it?