Skip to Content.
Sympa Menu

freetds - [freetds] dropped connection, I think

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Kass, Sharon" <Sharon.Kass AT gs.com>
  • To: "'freetds AT lists.ibiblio.org'" <freetds AT lists.ibiblio.org>
  • Cc: "Kass, Sharon" <Sharon.Kass AT gs.com>
  • Subject: [freetds] dropped connection, I think
  • Date: Mon, 1 Dec 2003 14:38:34 -0500

Hello,

Does anybody know what would cause a connection to be dropped (or a
secondary connection to be established)? And is there some way for me to
specify a username/password to be used if FreeTDS does try to re-connect?

Here's the details of my question:

I have a perl script which calls a function for each line of data in order
to insert into a database table. This is the code (snipit from function):

print "INSERT into gs_location VALUES
('$new_loc_id','$name','$db_building','$db_floor','$db_room',0,0,'',user_nam
e(),getdate())\n";

$db_cms_shadow->do("
INSERT into gs_location
VALUES
('$new_loc_id','$name','$db_building','$db_floor','$db_room',0,0,'',user_nam
e(),getdate())
");
print "Done with insert.\n";


The $db_cms_shadow variable is a global and set up in initialization
routine.

After a few (or after many) calls to this function there seems to be a
connection drop and then an attempt to re-establish the connection. I don't
know what values it is using to re-establish the connection. I am seeing:

DBD::Sybase::db do failed: OpenClient message: LAYER = (0) ORIGIN =
(0) SEVERITY = (78) NUMBER = (36)
Message String: Read from SQL server failed.
OpenClient message: LAYER = (0) ORIGIN = (0) SEVERITY = (78) NUMBER
= (46)
Message String: Login incorrect.


Here is the output from trace(2):


INSERT into gs_location VALUES ('1001041LO','ME1 E1011','RC ','ME1
','Outlets',0,0,'',user_name(),getdate())
-> do for DBD::Sybase::db (DBI::db=HASH(0x241de8)~0x164c68 '
INSERT into gs_location
VALUES ('1001041LO','ME1 E1011','RC ','ME1
','Outlets',0,0,'',user_name(),getdate())
')
1 -> prepare for DBD::Sybase::db (DBI::db=HASH(0x164c68)~INNER '
INSERT into gs_location
VALUES ('1001041LO','ME1 E1011','RC ','ME1
','Outlets',0,0,'',user_name(),getdate())
' undef)
syb_st_prepare() parent has active kids - opening new connection
!! ERROR: 46 'OpenClient message: LAYER = (0) ORIGIN = (0) SEVERITY =
(78) NUMBER = (46)
Message String: Login incorrect.
'
1 <- prepare= undef at Sybase.pm line 150
!! ERROR: 46 'OpenClient message: LAYER = (0) ORIGIN = (0) SEVERITY =
(78) NUMBER = (46)
Message String: Login incorrect.
'
<- do= undef at load_locations.pm line 209
DBD::Sybase::db do failed: OpenClient message: LAYER = (0) ORIGIN = (0)
SEVERITY = (78) NUMBER = (46)
Message String: Login incorrect.
DBD::Sybase::db do failed: OpenClient message: LAYER = (0) ORIGIN = (0)
SEVERITY = (78) NUMBER = (46)
Message String: Login incorrect.
-> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x242888)~INNER)
syb_st_finish() -> ct_cancel(CS_CANCEL_ALL)
syb_st_finish() -> resetting ACTIVE, moreResults, dyn_execed
syb_st_destroy: called on 274c10...
syb_st_destroy(): freeing imp_sth->statement
syb_st_destroy(): cmd dropped: 1
<- DESTROY= undef
-> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x242a74)~INNER)
Statement handle DBI::st=HASH(0x242a74) DESTROY ignored - never set up
<- DESTROY= undef
-- DBI::END
-> disconnect_all for DBD::Sybase::dr (DBI::dr=HASH(0x189468)~0x241df4)
<- disconnect_all= 1 at DBI.pm line 575
-> DESTROY for DBD::Sybase::st (DBI::st=HASH(0x242924)~INNER)
syb_st_finish() -> ct_cancel(CS_CANCEL_ALL)
syb_st_finish() -> resetting ACTIVE, moreResults, dyn_execed
syb_st_destroy: called on 243218...
syb_st_destroy: dirty set, skipping
<- DESTROY= undef during global destruction
-> DESTROY for DBD::Sybase::db (DBI::db=HASH(0x24e708)~INNER)
syb_db_disconnect() -> ct_close()
<- DESTROY= undef during global destruction
-> DESTROY for DBD::Sybase::db (DBI::db=HASH(0x164c68)~INNER)
syb_db_disconnect() -> ct_close()
<- DESTROY= undef during global destruction


I do have some handles to this database preparing and executing SELECT
statements before this insert and I noticed that if I added a line of code
after each select:
$sth->finish()
that this "dropped connection" problem is delayed to a later iteration of
the insert function. I'm not sure why this helps since I have auto-commit
set to 1, but I mention it here in case it helps explain anything.

Any help or ideas for a work-around would be greatly appreciated!
Sharon Kass
sharon.kass AT gs.com




Archive powered by MHonArc 2.6.24.

Top of Page