Skip to Content.
Sympa Menu

freetds - RE: [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 Development Group' <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] dropped connection, I think
  • Date: Mon, 1 Dec 2003 15:25:16 -0500

Thank you.

I'm not sure how to read useful information in the TDS dump but let me clip
the last few packets here in case someone can decipher:

Received header @ 2003-12-01 15:07:12.753709
0000 04 01 00 af 00 44 54 00 |.....DT.|


Received packet @ 2003-12-01 15:07:12.754070
<data deleted for public post by sharon>

2003-12-01 15:07:12.754856 swapping coltype 39
2003-12-01 15:07:12.755146 processing row. column is 3 varint size = 2
2003-12-01 15:07:12.755440 processing row. column size is 13
2003-12-01 15:07:12.757154 clearing column 3 NULL bit
2003-12-01 15:07:12.757428 swapping coltype 39
2003-12-01 15:07:12.757703 processing row. column is 4 varint size = 2
2003-12-01 15:07:12.757992 processing row. column size is 0
2003-12-01 15:07:12.758284 setting column 4 NULL bit
2003-12-01 15:07:12.758555 processing row. column is 5 varint size = 1
2003-12-01 15:07:12.758838 processing row. column size is 8
2003-12-01 15:07:12.759112 clearing column 5 NULL bit
2003-12-01 15:07:12.759400 swapping coltype 62
2003-12-01 15:07:12.759673 processing row. column is 6 varint size = 1
2003-12-01 15:07:12.759968 processing row. column size is 4
2003-12-01 15:07:12.760237 clearing column 6 NULL bit
2003-12-01 15:07:12.760514 swapping coltype 56
2003-12-01 15:07:12.760782 processing row. column is 7 varint size = 2
2003-12-01 15:07:12.761062 processing row. column size is 2
2003-12-01 15:07:12.761337 clearing column 7 NULL bit
2003-12-01 15:07:12.761616 swapping coltype 47
2003-12-01 15:07:12.761911 processing row. column is 8 varint size = 2
2003-12-01 15:07:12.762195 processing row. column size is 38
2003-12-01 15:07:12.762462 clearing column 8 NULL bit
2003-12-01 15:07:12.762748 swapping coltype 39
2003-12-01 15:07:12.763413 processing row. column is 9 varint size = 2
2003-12-01 15:07:12.763703 processing row. column size is 38
2003-12-01 15:07:12.764052 clearing column 9 NULL bit
2003-12-01 15:07:12.764331 swapping coltype 39
2003-12-01 15:07:12.764601 processing row. column is 10 varint size = 1
2003-12-01 15:07:12.764883 processing row. column size is 8
2003-12-01 15:07:12.765160 clearing column 10 NULL bit
2003-12-01 15:07:12.765447 swapping coltype 62
2003-12-01 15:07:12.765720 processing row. column is 11 varint size = 1
2003-12-01 15:07:12.766000 processing row. column size is 4
2003-12-01 15:07:12.766270 clearing column 11 NULL bit
2003-12-01 15:07:12.766566 swapping coltype 56
2003-12-01 15:07:12.766841 processing row. column is 12 varint size = 2
2003-12-01 15:07:12.767127 processing row. column size is 8
2003-12-01 15:07:12.767399 clearing column 12 NULL bit
2003-12-01 15:07:12.767689 swapping coltype 39
2003-12-01 15:07:12.767969 inside tds_process_end() more_results = 0,
was_cancelled = 0
Received header @ 2003-12-01 15:07:12.768294
0000 04 01 00 11 00 44 01 00 |.....D..|


Received packet @ 2003-12-01 15:07:12.768781
0000 fd 20 00 fd 00 00 00 00 00 |. ...... .|

2003-12-01 15:07:12.769130 inside tds_process_end() more_results = 0,
was_cancelled = 1
2003-12-01 15:07:12.769849 inside ct_close()
2003-12-01 15:07:12.770313 inside ct_con_drop()
2003-12-01 15:07:12.771410 inside ct_close()
2003-12-01 15:07:12.771841 inside ct_con_drop()


As for Sybase detecting an already open connection: My program does not
disconnect (well it will at the end but not during the processing of data).
Is there something else that might spark Sybase to close a connection? The
function that does the insert sometimes runs hundreds of times before having
this problem, sometimes only a few times before having the problem.

If you have any ideas, I'd be glad to have a direction to point myself.
Thank you!
Sharon


-----Original Message-----
From: Frediano Ziglio [mailto:freddyz77 AT tin.it]
Sent: Monday, December 01, 2003 2:59 PM
To: FreeTDS Development Group
Subject: Re: [freetds] dropped connection, I think


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


_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page