Ok. Sleuthing works. But how about "skuldiggering?"
It implies digging through the skulduggery of others ..!! o[;-) -----Original Message----- From: Roland Dumas [mailto:[EMAIL PROTECTED] Sent: Monday, December 13, 2004 2:58 PM To: [EMAIL PROTECTED] Subject: Re: Witango-Talk: WiTango Hangs on ODBC Connection - SOLVED (hopefully) I think you mean "sleuthing" ( Definition of skulduggery: trickery: verbal misrepresentation intended to take advantage of you in some way ) ;-) On 12/13/04 2:52 PM, "Ian Daniel" <[EMAIL PROTECTED]> wrote: > > Nice piece of skulduggery there, Dave ... hats' off to you. > > Ian > -----Original Message----- > From: Dave Machin [mailto:[EMAIL PROTECTED] > Sent: Monday, December 13, 2004 2:05 PM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Witango-Talk: WiTango Hangs on ODBC Connection - SOLVED > (hopefully) > > > We've been having serious WiTango (.065, W2K SP3, MS-SQL SP3) stability > issues over the last several days that I think we have finally figured out. > > The problem was that every few hours the web site would stop responding. If > we were sitting in front of a browser when the site started to slow down and > tested it we realized that connections to a particular one of several ODBC > names on the server were hanging. Even the exact same .taf application > could connect to database A, C, or D but would lock up against database B. > Eventually all the available WiTango threads were busy trying to connect to > database B. The site would only recover if we killed the WiTango process. > Also, the WiTango events log showed new connections being made to database B > every second - which didn't seem normal. > > To make a (very) long story short, here is what looks like was going on: > > Using MS-SQL Profiler to trace all WiTango activity on the database we > noticed the following sequence of events: > > WiTango issued a strange query to the database: SELECT 1 FROM 30DayTSNI > WHERE 1=0 > > Then it would close and reopen the database connection. > > Then it would issue a query involving SP_TABLES > > Then it would perform all the queries related to the page that was loading. > > Repeat each second or so. > > I assumed that the SELECT query was some kind of check WiTango does to make > sure the database connection is still open. 30DayTSNI is a table in the > suspect database and is the first user table listed. But, the question was > why did WiTango then drop and recreate the connection? > > Answer is that the query returns an error message unless you put [ ] around > the table name since the table name begins with a number. So, since the > query returned an error (even though the connection was valid) WiTango must > have thought the connection was broken and disposed of it and created a new > one. > > We renamed the table to not start with a number and WiTango appears to be > behaving very nicely again... > > So, it seems that if your database has user tables in them that begin with > numbers WiTango can get very unstable. > > I think it would be nice if With modified the connection pooling/keep alive > thing to handle this situation properly. > > Dave Machin > BenchmarkPortal.com > > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ----------------------------------------- Roland Dumas Roberts Information Services 310 W. Bellevue Avenue San Mateo CA 94402 650-347-1373 415-412-9300 (cell) [EMAIL PROTECTED] SMS: http://new.servqual.com/html/sms.tml ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
