FreeTDS Development Group

[Frediano Ziglio <freddyz77 AT tin.it>]

Il lun, 2003-12-01 alle 20:38, Kass, Sharon ha scritto:
> 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):
> 

A TDSDUMP (set TDSDUMP environment to a filename and post it discarding
unsafe data) would be helpful too.

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

It seem DBD::Sybase detect an already active connection so it try to
open another... 

> 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

freddy77