FreeTDS Development Group

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

Hi Jaye, 

Question for you...is it only nullable dates that don't work? If so, I
believe I have the answer.  

Warning: Long winded technical explaination coming
 
All the code to convert between datatypes is handled in the TDS
layer.  That way dblib, ctlib, odbc, and any future APIs can use the
common conversion code.  The code was originally in two places (dblib and
ctlib) but was merged and pushed down a layer some months ago.  Anyway,
the tds_convert() function accepts server datatypes (such as SYBCHAR,
SYBDATETIME, etc..) as opposed to the library specific types
(CS_CHAR_TYPE, CS_DATETIME_TYPE) so for each library there are two
functions to map back and forth.  For ctlib its _ct_get_server_type() and
_ct_get_client_type(). Anyway, this function was only mapping
DATETIME and DATETIME4 and missed DATETIMN.  Incidently, this seems to
affect a few other types as well. It should exhibit roughly the behaviour
you're describing.

It's all checked in so, let me know if it makes things any better (or
worse)

Brian

On Wed, 25 Aug 1999, Jaye Mathisen wrote:

> 
> Still not working, although it's closer.
> 
> dates don't seem to work at all now.  As soon as it hits a date, the
> parsing goes all to hell, although it seems to get sync'd back up for text
> fields.
> 
> 
> >From an old copy of sqsh:
> 
> 1> select name,username,guarantor,date,active from customer where
> username='mrcpu'
> 2> go
> name                                     username
> guarantor   date active 
> ---------------------------------------- ------------------------------
> ----------- ---- ------ 
> Jaye Mathisen                            mrcpu                          0
> Feb 05 1998 12:00AM Y      
> 
> (1 row affected)
> 
> 
> >From sqsh-1.7 with latest cvs snapshot:
> 
> 1> select name,username,guarantor,date,active from customer where
> username='mrcpu'
> 2> go
>  name                                     username
> guarantor  
>         date                                                                
>                                                         
>                                                                             
>                                                         
>         active
>  ---------------------------------------- ------------------------------
> -----------
> 
> ----------------------------------------------------------------------------------------------------------------------------
> ------------------------------------------------------------------------------------------------------------------------------------
>         ------
>  Jaye Mathisen                            mrcpu
> 0
>         o                                                                   
>                                                         
>                                                                             
>                                                         
>         Y     
> 
> (1 row affected)
> 
> 
> The DBD::Sybase output is both better and worse than before...
> 
> On Wed, 25 Aug 1999, Brian Bruns wrote:
> 
> > 
> > Okay, I just checked in the fix for the char datatypes. Basically what
> > happens is the string is null terminated and everythings good, except
> > DBD::Sybase also binds the length of the returned data and uses that as
> > the place to end the string. The length bind was returning the size of the
> > column instead of the size of the actual data. That is, a CHAR(30) column
> > containing "Test" would return 30 not 4.  main.t will return proper char
> > datatypes now.
> > 
> > The core dump is another matter though.  It happens with the message
> > callback stuff.  When a message comes in, tds calls ctlib which in turn
> > propagates the message up to the application (DBD::Sybase in this case).
> > So, ctlib stores the address of the callback function from dbdimp.c...
> > Somewhere along the way, and I think it has to do with the shared
> > libraries (a guess) trying to invoke the callback function core dumps it.
> > So, long story short (too late) if you can get by without message handler
> > then you're ok. Otherwise, this is going to be a real bitch to find out
> > whats wrong with it.
> > 
> > On Wed, 25 Aug 1999, Jaye Mathisen wrote:
> > 
> > > 
> > > Building the 0.46 FreeTDS release with TDS 4.2, and the 0.19 release of
> > > DBD::Sybase.
> > > 
> > > OS is FreeBSD 3.2.
> > > 
> > > One of the tests causes a coredump, t/main.t, 6 succeeds, 7 fails and
> > > cores perl.
> > > 
> > > 
> > > Doing some simple tests on a production 6.5 MSQL database shows
> > > some data corruption problems.
> > > 
> > > The fields names are retrieved OK, but the data is corrupted.  Name 
> > > should
> > > be just "Jaye Mathisen", date fields are missing things like the year,
> > > etc.
> > > 
> > > There are some of the unknown marker messages at the very beginning,
> > > unknown property 7 and 13.
> > > 
> > > sqsh1.7 with these libraries also has problems.
> > > 
> > > An older version of FreeTDS with sqsh-1.4 works fine.
> > > 
> > > 
> > > It is trivial to reproduce.  I can grab tcpdumps if you want.
> > > 
> > > 
> > > 
> > > output:
> > > 
> > >     syb_db_login() -> checking for chained transactions
> > >     syb_db_login() -> chained transactions are  supported
> > >     <- connect= DBI::db=HASH(0x8151dc8) at DBI.pm line 382.
> > >     -> STORE for DBD::Sybase::db (DBI::db=HASH(0x8151e10)~INNER
> > > 'PrintError' 1)
> > >     <- STORE= 1 at DBI.pm line 407.
> > >     -> STORE for DBD::Sybase::db (DBI::db=HASH(0x8151e10)~INNER
> > > 'AutoCommit' 1)
> > >     <- STORE= 1 at DBI.pm line 407.
> > >     <- connect= DBI::db=HASH(0x8151dc8)
> > >     -> do for DBD::Sybase::db (DBI::db=HASH(0x8151dc8)~0x8151e10 'use
> > > plat')
> > > 2   -> prepare for DBD::Sybase::db (DBI::db=HASH(0x8151e10)~INNER 'use
> > > plat' undef)
> > > 2   <- prepare= DBI::st=HASH(0x8151ef4) at Sybase.pm line 115.
> > >     -> execute for DBD::Sybase::st (DBI::st=HASH(0x8151ef4)~0x8151d44)
> > >     syb_st_execute() -> ct_send() OK
> > > ct_execute() final retcode = 15
> > >     <- execute= -1 at Sybase.pm line 116.
> > >     -> err in DBD::_::common for DBD::Sybase::st
> > > (DBI::st=HASH(0x8151ef4)~0x8151d44)
> > >     <- err= undef at Sybase.pm line 117.
> > >     -> rows for DBD::Sybase::st (DBI::st=HASH(0x8151ef4)~0x8151d44)
> > >     <- rows= -1 at Sybase.pm line 118.
> > >     -> FETCH for DBD::Sybase::st (DBI::st=HASH(0x8151d44)~INNER
> > > 'syb_more_results')
> > >     <- FETCH= undef at Sybase.pm line 119.
> > >     <- do= -1 at x.pl line 29.
> > > ok 2
> > >     -> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x8151d44)~INNER)
> > >     syb_st_destroy: called...
> > >     syb_st_destroy(): cmd dropped: 1
> > >     <- DESTROY= undef at x.pl line 34.
> > >     -> prepare for DBD::Sybase::db (DBI::db=HASH(0x8151dc8)~0x8151e10
> > > 'select * from customer where username='mrcpu'')
> > >     <- prepare= DBI::st=HASH(0x8151f3c) at x.pl line 36.
> > > ok 3
> > >     -> execute for DBD::Sybase::st (DBI::st=HASH(0x8151f3c)~0x8151d44)
> > >     syb_st_execute() -> ct_send() OK
> > >     st_next_result() -> ct_results(4) == 1
> > >     ct_res_info() returns 51 columns
> > > describe() retcode = 1
> > >     <- execute= -1 at x.pl line 39.
> > > ok 4
> > >     -> FETCH for DBD::Sybase::st (DBI::st=HASH(0x8151d44)~INNER
> > > 'NUM_OF_FIELDS')
> > >     <- FETCH= 51 at x.pl line 41.
> > > Fields: 51
> > >     -> FETCH for DBD::Sybase::st (DBI::st=HASH(0x8151d44)~INNER 'NAME')
> > >     <- FETCH= [ 'id' 'name' 'guarantor' 'taxrate' 'taxrate2' 'date'
> > > 'active' 'taxid' 'staffnum' 'timestamp' 'attn' 'addr1' 'addr2' 'city'
> > > 'state' 'zip' 'phone' 'fax' 'username' 'password' 'email' 'stmtmethod'
> > > 'emailrcpt' 'laststmt' 'nextstmt' 'custbillday' 'nostatement'
> > > 'nolatenotice' 'nodeactivate' 'latedate' 'deactivatedate' 'stacktype'
> > > 'machtype' 'referralid' 'referral' 'comment' 'cctype' 'ccnumber' 
> > > 'ccdate'
> > > 'cuskey' 'birthday' 'timeleft' 'blockuser' 'shellid' 'websignup'
> > > 'ponumber' 'routenumber' 'damount' 'dtype' 'salesid' 'lastusername' ] at
> > > x.pl line 42.
> > > Names: id name guarantor taxrate taxrate2 date active taxid staffnum
> > > timestamp attn addr1 addr2 city state zip phone fax username password
> > > email stmtmethod emailrcpt laststmt nextstmt custbillday nostatement
> > > nolatenotice nodeactivate latedate deactivatedate stacktype machtype
> > > referralid referral comment cctype ccnumber ccdate cuskey birthday
> > > timeleft blockuser shellid websignup ponumber routenumber damount dtype
> > > salesid lastusername
> > >     -> FETCH for DBD::Sybase::st (DBI::st=HASH(0x8151d44)~INNER
> > > 'NULLABLE')
> > >     <- FETCH= [ '' 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
> > > 1 1
> > > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 ] at x.pl line 43.
> > > Null:   1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 
> > > 1
> > > 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
> > >     -> fetchrow for DBD::Sybase::st (DBI::st=HASH(0x8151f3c)~0x8151d44)
> > >     <- fetchrow= ( 10196 'Jaye Mathisen.customer where username='m' 0 
> > > '..'
> > > 'id.:' 'Feb 05 1' 'Y' undef 5 0 ' ................... 
> > > ...................'
> > > '3321 Bellinger Lane.........................................' '
> > > ...........................................................'
> > > 'Medford.............' 'OR.......................' '97501...=='
> > > '5417799176.}
> > > 
> > > 1' ' ....._
> > > 
> > > =hea' 'mrcpu.........................'
> > > 'pac43lg4nj......................................'
> > > 'mrcpu AT cdsnet.net.E.....#.Changed database context to
> > > 'plat'..DB01.............' 'EMAIL...............' 'Y' 'Aug 04 1' 'Sep 01
> > > 1' 1 'N' 'N' 'Y' 'Aug 21 1' undef undef undef 0 undef undef undef undef
> > > undef undef 'Jul 17 1' undef undef 1 undef undef undef undef undef undef
> > > undef ) [51 items] at x.pl line 45.
> > > 10196 Jaye Mathisencustomer where username='m   id: Feb 05 1 Y  5    
> > > 3321
> > > Bellinger Lane   Medford OR 9750== 5417799176}
> > > 
> > > 1 _
> > > 
> > > =hea mrcpu pac43lg4nj mrcpu AT cdsnet.netE#Changed database context to
> > > 'plat'.DB01 EMAIL Y Aug 04 1 Sep 01 1 1 N N Y Aug 21 1           Jul 17 
> > > 1
> > > 1       
> > >     -> fetchrow for DBD::Sybase::st (DBI::st=HASH(0x8151f3c)~0x8151d44)
> > >     st_next_result() -> ct_results(14) == 1
> > > ct_execute() final retcode = 15
> > >     syb_st_fetch() -> st_next_results() == 14
> > >     <- fetchrow= ( ) [0 items] at x.pl line 45.
> > >     -> rows for DBD::Sybase::st (DBI::st=HASH(0x8151f3c)~0x8151d44)
> > >     <- rows= 1 at x.pl line 52.
> > > ok 5
> > >     -> disconnect for DBD::Sybase::db 
> > > (DBI::db=HASH(0x8151dc8)~0x8151e10)
> > >     syb_db_disconnect() -> ct_close()
> > >     <- disconnect= 1 at x.pl line 62.
> > >     -> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x8151d44)~INNER)
> > >     syb_st_destroy: called...
> > >     syb_st_destroy(): cmd dropped: 1
> > >     <- DESTROY= undef at unknown location!
> > >     -> DESTROY for DBD::Sybase::db (DBI::db=HASH(0x8151e10)~INNER)
> > >     <- DESTROY= undef at unknown location!
> > >     -> DBI::END
> > >     -> disconnect_all for DBD::Sybase::drr=HASH(0x8151e58)~INNER)
> > >     <- DESTROY= undef during global destruction.
> > >     -> DESTROY in DBD::_witch::dr (DBI::dr=HASH(0x80b9a34)~INNER)
> > >     <- DESTROY= undef during global destruction.
> > > 
> > > 
> > > ---
> > > You are currently subscribed to freetds as: camber AT ais.org
> > > To unsubscribe, forward this message to $subst('Email.Unsub')
> > > 
> > > 
> > 
> > 
> > ---
> > You are currently subscribed to freetds as: mrcpu AT internetcds.com
> > To unsubscribe, forward this message to $subst('Email.Unsub')
> > 
> 
> 
> ---
> You are currently subscribed to freetds as: camber AT ais.org
> To unsubscribe, forward this message to $subst('Email.Unsub')
> 
>