| if the problem goes away, when you DO NOT use a var for the DSN, then it would seem it must be a programming issue.
I would guess a variable is expiring, and not re-initializing, or not re-initialing correctly.
One thing that we do, is we have a file, called "checkobjects.inc". This file has code in it, that verifies that certain objects, like TCFs, or coms, or certain globally scoped vars are set properly. If they are not, it sets them. It does the same stuff that our app should do on startup. This check objects file, is inserted as an include ON EVERY SINGLE witango page that may or may not use those objects. This ensures we don't have a problem.
For instance, your db hangs up, and witango dies and restarts itself, and doesn't load certain objects/vars properly, by having this INCLUDE, it eliminates the problem.
If you go to any one of my sites, if you look at source code, you will see something like this embedded in the HTML:
<!-- Check Eventpix Widgets Start Timer: 1 --> <!-- Just Checking the Eventpix Object Status Listener Address: 66.201.40.79 Current Object: [Object: 0BA49220] -->
<!-- Check Eventpix Widgets End Timer: 1 --> <!-- Check BigHead Widgets Start Timer: 1 --> <!-- Just Checking the BigHead Object Status Listener Address: 66.201.40.79 Current Object: [Object: 0BAA9940] --> <!-- Check BigHead Widgets End Timer: 1 -->
This is the output of the checkobjects code, and you can see, the whole thing, less than 1ms. If it just checks, takes no time, takes longer if something needs to be initialized. I don't know if that is your problem, but it sounds like something similar to this type of issue.
HTH.
--
Robert Garcia President - BigHead Technology VP Application Development - eventpix.com 13653 West Park Dr Magalia, Ca 95954 ph: 530.645.4040 x222 fax: 530.645.4040 On Jan 16, 2006, at 10:30 AM, Alan Wolfe wrote: Do you think the problem might be in the ODBC layer itself? can you verify whether or not witango is telling ODBC to use the correct datasource and maybe ODBC just isnt?
On 1/16/06, Dave Machin <[EMAIL PROTECTED]> wrote: Here's what we know:
It seems that the other data sources are chosen at random - it's not always
defaulting to the "set development data source" data source, like I thought
it might have been earlier.
We can't find any scoping errors. The ODBC name variable is user scope, and
we show that it is correctly set in the DBMS action in question. We write
the contents of the variable to a hidden field in the form created in the
results action of the DBMS action. We can see the hidden field data in
witango's log file when the user submits the form and the hidden field value
is correct.
We don't have a full debug showing the problem, we'll try and get one. The
problem queries generally don't generate errors because the table structures
of the databases used by the data sources is the same, so the query would
work without error on any of the data sources - it just reads the wrong
information.
As far as patterns:
The problem started two days after upgrading from 5.0.1.065 to 5.5.009 -
although other things were changed in that time period - we're trying to
eliminate all the other changes to see if it goes away.
The problem seems to happen during periods when WiTango is responding more
slowly than normal. Problems occur clumped into a few hours and then don't
happen again that day. Page response times are somewhat slow during the
hours that the problem happens. Some customer's complain about "sluggish"
response for the same time period. This could be because the MS-SQL
database is busy doing scheduled jobs and isn't as responsive to WiTango as
normal - but we're not sure.
We upgraded two servers from 5.0.1.065 to 5.5.009 at the same time. Both
have the problem, although one server is much more frequent. Server A had 4
occurrences in one database in two months, where B had 150 for the same time
period. We track "current connection" to IIS in performance monitor all the
time and the connections to B started averaging much higher than normal
after the upgrade (from 50 to 60 at any given time to 200 to 300, upwards of
1000). Server A didn't exhibit this behavior after upgrading.
We're downgrading one of the two servers back to 5.0.1.065 without changing
anything else to see if the problem goes away.
Any other help or ideas would be greatly appreciated.
Dave Machin
[EMAIL PROTECTED]
----- Original Message -----
From: "Robert Shubert" <[EMAIL PROTECTED] >
To: <[email protected]>
Sent: Friday, January 13, 2006 4:53 PM
Subject: RE: Witango-Talk: WiTango Uses Wrong ODBC Connection
> Dave,
>
> Is the other datasource chosen randomly?
> Have you scoped all the variable assignments and calls?
> Can you produce a debug that shows the problem happening?
> Is there any reproducible pattern?
>
> Robert
>
> -----Original Message-----
> From: Dave Machin [mailto:[EMAIL PROTECTED]]
> Sent: Friday, January 13, 2006 6:22 PM
> To: [email protected]
> Cc: [EMAIL PROTECTED]
> Subject: Witango-Talk: WiTango Uses Wrong ODBC Connection
>
> We've definitely verified that WiTango is sometimes using the wrong
database
> connection for a query.
>
> In fact, it will use the correct connection for one action and then two
> actions later in the same request use a different connection (which goes
to
> a different database and returns the wrong results).
>
> We're using a user scope variable to specify the ODBC data source name and
> have confirmed that the value in that variable is correct when the action
is
> called even though WiTango is connecting to the wrong database.
>
> Does anyone have any ideas where to start troubleshooting this? Our ODBC
> driver is MS-SQL and is version 2000.85.1025.00 , WiTango 5.5.009, Windows
> 2000 Server.
>
> Dave Machin
> [EMAIL PROTECTED]
>
>
> ________________________________________________________________________
> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>
> ________________________________________________________________________
> TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
>
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
________________________________________________________________________
TO UNSUBSCRIBE: Go to http://www.witango.com/developer/maillist.taf
|
