Re: Connecting to Sybase with perl+DBI::ODBC results in an error?

On Wed, Dec 01, 2010 at 10:05:44AM -0500, Peter C. Norton wrote:
> 
> any ideas about where this is coming from?  In the mean time, I'll try
> to see if I can delay/change where in the connection the autocommit is
> set and see if that helps.
> 

Stranger and stranger.  It looks like if I take out the autocommit
attribute from the DBI module, and from the post-connection function
in DBD::ODBC, the prepare() function in DBD::ODBC will come back with
an error:

token.c:337:looking for login token, got  e3(ENVCHANGE)
token.c:122:tds_process_default_tokens() marker is e3(ENVCHANGE)
token.c:2615:server indicated charset change to "iso_1"
iconv.c:1025:setting server single-byte charset to "ISO-8859-1"
token.c:337:looking for login token, got  e5(EED)
token.c:122:tds_process_default_tokens() marker is e5(EED)
token.c:2710:tds_process_msg() reading message 5704 from server
token.c:2783:tds_process_msg() calling client msg handler
odbc.c:2273:msgno 5704 20003
token.c:2796:tds_process_msg() returning TDS_SUCCEED
token.c:337:looking for login token, got  e3(ENVCHANGE)
token.c:122:tds_process_default_tokens() marker is e3(ENVCHANGE)
token.c:337:looking for login token, got  e5(EED)
token.c:122:tds_process_default_tokens() marker is e5(EED)
token.c:2710:tds_process_msg() reading message 5701 from server
token.c:2783:tds_process_msg() calling client msg handler
odbc.c:2273:msgno 5701 20003
token.c:2796:tds_process_msg() returning TDS_SUCCEED
token.c:337:looking for login token, got  e3(ENVCHANGE)
token.c:122:tds_process_default_tokens() marker is e3(ENVCHANGE)
token.c:2599:changing block size from  to 512
token.c:337:looking for login token, got  ad(LOGINACK)
token.c:372:server reports TDS version 5.0.0.0
token.c:374:Product name for 0x5000000 is unknown
token.c:337:looking for login token, got  e2(CAPABILITY)
token.c:122:tds_process_default_tokens() marker is e2(CAPABILITY)
token.c:337:looking for login token, got  fd(DONE)
token.c:122:tds_process_default_tokens() marker is fd(DONE)
token.c:2461:tds_process_end: more_results = 0
                was_cancelled = 0
                error = 0
                done_count_valid = 0
token.c:2477:tds_process_end() state set to TDS_IDLE
token.c:2492:                rows_affected = 49
token.c:437:tds_process_login_tokens() returning TDS_SUCCEED
odbc.c:4919:SQLGetFunctions: fFunction is 999
odbc.c:5834:SQLGetInfo(0x150a62c0, 77, 0x14f3d2c8, 20, 0x7fff0176ae0e)
odbc.c:5088:_SQLGetInfo(0x150a62c0, 77, 0x14f3d2c8, 20, 0x7fff0176ae0e)
odbc.c:5834:SQLGetInfo(0x150a62c0, 6, 0x14f3d340, 80, 0x7fff0176ae0e)
odbc.c:5088:_SQLGetInfo(0x150a62c0, 6, 0x14f3d340, 80, 0x7fff0176ae0e)
odbc.c:5834:SQLGetInfo(0x150a62c0, 7, 0x14f3d390, 20, 0x7fff0176ae0e)
odbc.c:5088:_SQLGetInfo(0x150a62c0, 7, 0x14f3d390, 20, 0x7fff0176ae0e)
error.c:517:SQLGetDiagRec(2, 0x150a62c0, 1, 0x7fff0176ab80, 0x7fff0176ab9c, 0x7fff0176a980, 512, 0x7fff0176ab98)
error.c:517:SQLGetDiagRec(2, 0x150a62c0, 1, 0x7fff0176abf0, 0x7fff0176ac0c, 0x7fff0176a9f0, 512, 0x7fff0176ac08)
odbc.c:5834:SQLGetInfo(0x150a62c0, 17, 0x14f3d3a4, 80, 0x7fff0176ae0e)
odbc.c:5088:_SQLGetInfo(0x150a62c0, 17, 0x14f3d3a4, 80, 0x7fff0176ae0e)
odbc.c:5834:SQLGetInfo(0x150a62c0, 18, 0x14f3d3f4, 80, 0x7fff0176ae0e)
odbc.c:5088:_SQLGetInfo(0x150a62c0, 18, 0x14f3d3f4, 80, 0x7fff0176ae0e)
odbc.c:5834:SQLGetInfo(0x150a62c0, 30, 0x14f3d2dc, 2, 0x7fff0176ae0e)
odbc.c:5088:_SQLGetInfo(0x150a62c0, 30, 0x14f3d2dc, 2, 0x7fff0176ae0e)
odbc.c:1719:SQLAllocStmt(0x150a62c0, 0x150aa010)
odbc.c:1618:_SQLAllocStmt(0x150a62c0, 0x150aa010)
odbc.c:4448:SQLPrepare(0x150aa280, select count(*) from master..sysobjects, -3)
odbc.c:4493:Creating prepared statement
mem.c:615:tds_free_all_results()
util.c:156:Changed query state from IDLE to QUERYING
util.c:156:Changed query state from QUERYING to PENDING
net.c:730:Sending packet
0000 0f 01 00 5b 00 00 00 00-e7 50 00 01 00 0a 69 63 |...[.... P....ic|
0010 61 30 33 38 36 30 30 30-41 00 63 72 65 61 74 65 |a0386000 A.create|
0020 20 70 72 6f 63 20 69 63-61 30 33 38 36 30 30 30 | proc ic a0386000|
0030 20 61 73 20 73 65 6c 65-63 74 20 63 6f 75 6e 74 | as sele ct count|
0040 28 2a 29 20 66 72 6f 6d-20 6d 61 73 74 65 72 2e |(*) from  master.|
0050 2e 73 79 73 6f 62 6a 65-63 74 73                |.sysobje cts|

token.c:539:tds_process_tokens(0x150a7d50, 0x7fff0176b0cc, 0x7fff0176b0c8, 0x104)
util.c:156:Changed query state from PENDING to READING
net.c:546:Received header
0000 04 01 00 08 00 00 00 00-                        |........|

net.c:600:Received packet
0000 04 01 00 08 00 00 00 00-                        |........|

util.c:331:tdserror(0x150a3f60, 0x150a7d50, 20017, 115)
odbc.c:2273:msgno 20017 20003
util.c:361:tdserror: client library returned TDS_INT_CANCEL(2)
util.c:384:tdserror: returning TDS_INT_CANCEL(2)
util.c:156:Changed query state from READING to DEAD
token.c:554:processing result tokens.  marker is  0()
token.c:122:tds_process_default_tokens() marker is 0()
token.c:125:leaving tds_process_default_tokens() connection dead
util.c:104:logic error: cannot change query state from DEAD to PENDING
error.c:517:SQLGetDiagRec(3, 0x150aa280, 1, 0x7fff0176b080, 0x7fff0176b09c, 0x7fff0176ae80, 512, 0x7fff0176b098)
error.c:566:SQLGetDiagRec: "[FreeTDS][SQL Server]Unexpected EOF from the server"
error.c:517:SQLGetDiagRec(3, 0x150aa280, 2, 0x7fff0176b080, 0x7fff0176b09c, 0x7fff0176ae80, 512, 0x7fff0176b098)
odbc.c:3983:SQLFreeHandle(3, 0x150aa280)
odbc.c:4078:_SQLFreeStmt(0x150aa280, 1, 0)
odbc.c:4628:SQLTransact((nil), 0x150a62c0, 1)
odbc.c:4619:_SQLTransact((nil), 0x150a62c0, 1)
odbc.c:4580:change_transaction(0x0x150a62c0,0)
util.c:131:logic error: cannot change query state from DEAD to QUERYING
util.c:331:tdserror(0x150a3f60, 0x150a7d50, 20006, 0)
odbc.c:2273:msgno 20006 20003
[etc.]

There's an unprintable character right after net.c:730 (sending
packet... the e7) that I can't cut-n-paste - my terminals have become
picky about this.

Anyway, I'm including this much context in the hope that the sequence
of events here leads to a reason for this.  I can provide more info if
I've missed anything.  The unixODBC trace and the perl dbi trace don't
look like they add anything to this.

-Peter