In the XML, I'm not entirely sure what I'm looking for. The first query shows "var user$odbc.2" as the data source and the second shows "var user$odbc.2" Not sure what the .2 part refers to?
Anything else I should be looking for? ----- Original Message ----- From: "William M Conlon" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Wednesday, January 25, 2006 11:44 AM Subject: Re: Witango-Talk: Select 1 From xxx where 1=0 > I would also follow RG's suggestion and closely examine the xml. > > On Jan 25, 2006, at 11:38 AM, Dave Machin wrote: > > > Thanks for noticing - I've made them match to see what happens... > > > > ----- Original Message ----- > > From: "William M Conlon" <[EMAIL PROTECTED]> > > To: <[email protected]> > > Sent: Wednesday, January 25, 2006 11:11 AM > > Subject: Re: Witango-Talk: Select 1 From xxx where 1=0 > > > > > >> One difference is > >> > >> the first action has Name: <@var "[EMAIL PROTECTED]"> > >> > >> while the second is unquoted: <@var user$odbc> > >> > >> On Jan 25, 2006, at 10:46 AM, Dave Machin wrote: > >> > >>> Thanks for the feedback. > >>> > >>> We're still stumped. We've confirmed that the ODBC variable is set > >>> correctly before and after our two test queries, and yet one of the > >>> two (or > >>> sometimes both) execute against the wrong data source. Queries > >>> that happen > >>> later or earlier in the request execute against the correct data > >>> source. > >>> > >>> I've compiled some notes of one example from this morning, if > >>> anyone has > >>> some time they could take a look and see what we're seeing. > >>> > >>> You can download the document here: > >>> www.benchmarkportal.com/witango_error_notes.zip > >>> > >>> In short, we're showing that queries execute correctly at first; > >>> the user > >>> variable is correct before the query in question; the first test > >>> query then > >>> executes against the wrong data source; the second test query > >>> executes > >>> against the correct data source; and then the next query executes > >>> correctly > >>> as well. > >>> > >>> This happens in 5.5.009 on three different servers. The current > >>> production > >>> server is a new, clean build with the latest updates and the latest > >>> MDAC > >>> drivers. This .taf does not use the user reference argument, and > >>> relies on > >>> the cookie. What's confusing is that one query in the middle of a a > >>> sequence of ten goes wrong and the others work fine - all in the > >>> same > >>> request. > >>> > >>> We're going to downgrade from 5.5 back to 5.0 to see if the problem > >>> goes > >>> away, because we can't find anything else to change. > >>> > >>> ----- Original Message ----- > >>> From: "Customer Support" <[EMAIL PROTECTED]> > >>> To: <[email protected]> > >>> Sent: Tuesday, January 24, 2006 5:32 PM > >>> Subject: Re: Witango-Talk: Select 1 From xxx where 1=0 > >>> > >>> > >>>>> Is it unusual that our production server doesn't issue the > >>>>> heartbeat query before each DB action? > >>>> > >>>> Yes. It may be going to another DB or DB Server as it is based on > >>>> the datasource and tables in the db. > >>>> > >>>>> On our development machine, I wrote a .taf application that issued > >>>>> an identical DB action 20 times (just copied and pasted the same > >>>>> DBMS action over and over). In SQL profiler, when that > >>>>> application > >>>>> is executed, I see the heartbeat and then the query repeated 20 > >>>>> times in pairs as expected. > >>>>> > >>>>> But on our production server, we often see cases where there is no > >>>>> heartbeat query before a DBMS action. Sometimes we see two or > >>>>> three DB actions execute before we see another heartbeat query. > >>>> > >>>> If you are running the same version of the Witango Server, OS, ODBC > >>>> and DB on all servers and they are exhibiting different behaviors > >>>> then you probably have a difference in the configuration of one or > >>>> more of Witango Server, OS, ODBC and/or DB processes. > >>>> > >>>> Your problem sounds like tafs interacting with eachother, hard > >>>> coded > >>>> user references, lost user reference cookies or lost user > >>>> references > >>>> argument. If you do not use user reference arguments and rely > >>>> on the > >>>> user reference cookie make sure that it is working and has a > >>>> value or > >>>> the server will fall back to issuing a new user reference cookie. > >>>> > >>>> If you are using iframes or AJAX check that you do not have one taf > >>>> interacting with another under the same user reference reseting a > >>>> variable when you are not expecting it. > >>>> > >>>> > >>>> Witango Support > >>>> ___________________________________________________________________ > >>>> __ > >>>> ___ > >>>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >>>> > >>> > >>> > >>> ____________________________________________________________________ > >>> __ > >>> __ > >>> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >> > >> Bill > >> > >> William M. Conlon, P.E., Ph.D. > >> To the Point > >> 345 California Avenue Suite 2 > >> Palo Alto, CA 94306 > >> vox: 650.327.2175 (direct) > >> fax: 650.329.8335 > >> mobile: 650.906.9929 > >> e-mail: mailto:[EMAIL PROTECTED] > >> web: http://www.tothept.com > >> > >> _____________________________________________________________________ > >> ___ > >> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > >> > > > > ______________________________________________________________________ > > __ > > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > > Bill > > William M. Conlon, P.E., Ph.D. > To the Point > 345 California Avenue Suite 2 > Palo Alto, CA 94306 > vox: 650.327.2175 (direct) > fax: 650.329.8335 > mobile: 650.906.9929 > e-mail: mailto:[EMAIL PROTECTED] > web: http://www.tothept.com > > ________________________________________________________________________ > TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf > ________________________________________________________________________ TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
