Re: Getting DB error = 20017 - Unexpected EOF from the server

"Jackson, Craig (Gale)" <[email protected]>
Newsgroups gmane.comp.db.tds.freetds
Message-ID <[email protected]>
Jeff,

Are there any firewalls or other "intelligent" network devices in the path?

Was this all done on one TDS connection?

Perhaps something has decided that such a connection is too long, or perhaps some counter has overflowed.

Craig 

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Tuesday, March 17, 2009 2:03 PM
To: FreeTDS Development Group
Subject: Re: [freetds] Getting DB error = 20017 - Unexpected EOF from the server

[email protected] wrote on 03/16/2009 09:24:08 PM:

Thanks for your response.

The failure occurred within the 25 hours again.

20090318002607 Successfully inserted PTNO: ZS10241810
DB error = 20004,  Severity code = 9
DB error msg Read from the server failed
OS error # 54
OS error msg connection reset by peer
Error string is: connection reset by peer
DB error = 20047,  Severity code = 1
DB error msg DBPROCESS is dead or not enabled
OS error # 0
OS error msg error 0
Error string is: error 0
FreeTDS: db-lib: exiting because client error handler returned 0 for msgno 
20047
  SYSTEM       job terminated at 18-MAR-2009 00:39:58.54
  Charged CPU time:        0 00:02:07.00      Elapsed time:       1 
00:25:35.08


> [email protected] wrote:
> > [email protected] wrote on 03/15/2009 06:13:21 PM:
> 
> Is the server implementation changing, too, or just the client? 

The server is static.  It is the same server the production VAX systems 
hit against, although the DB we are using is a test DB instead of the 
production DB.

> 
> 
> Keep posting the tail end of the TDSDUMP logs, though, especially the 
last
> packet sent.  I can't help thinking we're overlooking something, a bit 
set
> or reset, that constitutes a protocol violation and is cause for
> termination, as it were.  But my leading suspect is either an 
intermediary
> closing the connection, or something (perhaps even something about the
> client TCP implementation) causing the server's TCP to close the
> connection.  None of which seems likely to me, either. 

I've posted the latest tail end at the end of this message.

> 
> > I've implemented the changes from the diff file you supplied as well 
as 
> > the strerror() change you suggested.
> 
> Excellent.  Next time you post, please include a universal diff if it's
> not too much trouble (against the unmodified tarball).  Or even just 
net.c
>  Just to make sure what you did is what I think you did, and all that. 

I'll attach the whole net.c.  The OpenVMS diff command is substantially 
different from the unix command.

> 
> HTH. 
> 
> --jkl
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]token.c;1:2217:tds_process_end() 
state set to TDS_IDLE
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:162:Changed query 
state from READING to IDLE
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]token.c;1:2232: rows_affected 
= 0
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:110:logic error: 
cannot change query state from IDLE to PENDING
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:4601:dbsqlok() end 
status was success
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:1243:dbcmd(BF9AB0, 
set rowcount 1)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:1250:dbcmd() bufsz 
= 15
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:5727:dbfreebuf(BF9AB0)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:1298:dbsqlexec(BF9AB0)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:6722:dbsqlsend(BF9AB0)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]mem.c;1:563:tds_free_all_results()
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:162:Changed query 
state from IDLE to QUERYING
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:162:Changed query 
state from QUERYING to PENDING
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]net.c;5:784:Sending packet
0000 0f 01 00 1c 00 00 00 00-21 0f 00 00 00 00 73 65 |........ !.....se|
0010 74 20 72 6f 77 63 6f 75-6e 74 20 31             |t rowcou nt 1|

SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:4532:dbsqlok(BF9AB0)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:334:tdserror(BF9970, 
BF9DD0, 20004, 54)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7782:dbperror(BF9AB0, 
20004, 54)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7835:20004: "Read 
from the server failed"
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:4747:dbdead(BF9AB0) 
[alive]
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7856:"Read from 
the server failed", client returns 2 (INT_CANCEL)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:368:tdserror: client 
library returned TDS_INT_CANCEL(2)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:389:tdserror: 
returning TDS_INT_CANCEL(2)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:162:Changed query 
state from PENDING to DEAD
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:4565:dbsqlok() not 
done, calling tds_process_tokens()
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]token.c;1:495:tds_process_tokens(BF9DD0, 
7ACDFB00, 7ACDFB08, 0x6914)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.TDS]util.c;3:118:logic error: 
cannot change query state from DEAD to READING
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:1243:dbcmd(BF9AB0, 
update INFOTAP)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7782:dbperror(BF9AB0, 
20047, 0)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7835:20047: 
"DBPROCESS is dead or not enabled"
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:4747:dbdead(BF9AB0) 
[dead]
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7856:"DBPROCESS is 
dead or not enabled", client returns 0 (INT_EXIT)
SYS$SYSDEVICE:[FREETDS.FREETDS-0_82.SRC.DBLIB]dblib.c;1:7903:FreeTDS: 
db-lib: exiting because client error handler returned 0 for msgno 20047
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.