Skip to Content.
Sympa Menu

freetds - Re: Better/notsobetter... Re: DBD::Sybase 0.19 and snapshot from today.

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Jaye Mathisen <mrcpu AT internetcds.com>
  • To: Brian Bruns <camber AT umcc.ais.org>
  • Cc: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Better/notsobetter... Re: DBD::Sybase 0.19 and snapshot from today.
  • Date: Thu, 26 Aug 1999 17:33:20 -0700 (PDT)



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')
>





Archive powered by MHonArc 2.6.24.

Top of Page