FreeTDS Development Group

[Jaye Mathisen <mrcpu AT internetcds.com>]

What's weirder is that DBD::Sybase is now getting it basically right, with
the exception of 1 type of field, and all the error messages about the
conversion errors.

It appears to be a float conversion problem.

 id: |10196|
 name: |Jaye Mathisen|
 guarantor: ||
 taxrate: ||
 taxrate2: ||
 date: |Feb 05 1998 12:00AM|
 active: |Y|
 taxid: ||

taxrate and taxrate2 are type real size 4, nullable

I'll try to figure out how to send you the ddl stuff...

On Thu, 26 Aug 1999, Brian Bruns wrote:

> 
> DDL for the table and an insert statement to populate it would be great.
> (Then I really have no reason for not totally fixing it)
> 
> Brian
> 
> On Thu, 26 Aug 1999, Jaye Mathisen wrote:
> 
> > 
> > Better, but now other weirdness.
> > 
> > dates seem to work, but other fields that didn't seem to have problems are
> > freaked, and there's still some garbage in there.  This is from a snapshot
> > grabbed this afternoon.
> > 
> > note the appearance of "taxrate" in the output stream, and it or taxrate2
> > seem to be the first of the messed up columns.
> > 
> > Lots of these "unknown source types". now, that I wasn't getting.
> > 
> > BTW, for the record, the password field in here means absolutely nothing
> > in this table, it is populated, but unused.  So no freebies. :).
> > 
> > If it would help, I can send a schema for the table, or snatch tcpdump
> > traffic, or arrange for access to the DB for a quick test...
> > 
> > BTW, it's a 6.5 server.
> > 
> > 
> > 1> select * from customer where username='mrcpu'
> > 2> go
> > Attempting to convert unknown source type 122
> >  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
> >  ----------- ---------------------------------------- -----------
> > -------------------- -------------------- -------------------
> >         ------ -------------------- -------- ----------
> > ----------------------------------------
> >         ------------------------------------------------------------
> > ------------------------------------------------------------
> >         -------------------- ------------------------- ----------
> > --------------- --------------- ------------------------------
> >         ------------------------------------------------
> > 
> > --------------------------------------------------------------------------------
> > -------------------- ---------
> >         ------------------- ------------------- ----------- -----------
> > ------------ ------------ -------------------
> >         ------------------- ------------------------------
> > ------------------------------ -----------
> >         ------------------------------------------------------------
> > 
> > ----------------------------------------------------------------------------------------------------------------------------
> > ------------------------------------------------------------------------------------------------------------------------------
> >         --------------------
> > ------------------------------------------------ -------------------
> > --------------------
> >         ------------------- ----------- --------- ------- ---------
> > -------------------- -------------------- --------------------
> >         ----- -------
> > ----------------------------------------------------------------------------------------------------
> > Attempting to convert unknown source type 59
> > Attempting to convert unknown source type 59
> > Attempting to convert unknown source type 37
> > Attempting to convert unknown source type 122
> >        10196 Jaye Mathisen                                      0
> > 0.000000 70062382309412494639104.000000 Feb 05 1998 12
> > :00AM
> >         Y      NULL                        5    taxrate
> >         3321 Bellinger Lane
> >         Medford              OR                        97501
> > 5417799176                      mrcpu
> >         pac43lg4nj
> >         mrcpu AT cdsnet.net
> > EMAIL                Y
> >         Aug 04 1999 09:42AM Sep 01 1999 12:00AM           1 N           N
> > Y            Aug 21 1999 11:46AM
> >                        NULL NULL                           NULL
> > 0
> >         NULL
> >         NULL
> > 
> >         NULL                 NULL
> > NULL NULL
> >         Jul 17 1964 12:00AM        NULL NULL            1 NULL      NULL
> > NULL                                 NULL
> >         NULL     NULL NULL
> > Attempting to convert unknown source type 59
> > Attempting to convert unknown source type 59
> > Attempting to convert unknown source type 37
> > 
> > 
> > On Wed, 25 Aug 1999, Brian Bruns wrote:
> > 
> > > 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: mrcpu AT internetcds.com
> To unsubscribe, forward this message to $subst('Email.Unsub')
>