This has been driving me nuts for about a year. It's now imperative that I fix it.
Mostly well-established code on established web sites running for at least two or three years.
There is no error on a local Windows 2000 dev server
There was no error on a previous 2003/IIS6 server.
About a year ago I transferred every site to a new 2003/IIS6 server (different datacentre so possibly different OS build). Four or five sites immediatley gave the 0115 but very infrequently - some sites maybe once a week, four or five times a day on the most-accessed sites.
I tried several things and went through all I could find about the error online. I even tried running the IIS debug software: the output made no sense. I separated the "broken" sites into their own App Pools, no change. Hosting company has no idea. I ran out of time and decided that the errors were sufficiently infrequent as to be ignorable.
Most of the affected sites access an MDB database (different one for each site); one (site SD) uses MySql. They use the same library code as several dozen other sites that also access MDB's and MySql's with no problem, even though some other sites have higher access rates.
I have now added a new layer of software to a few test sites, notably one that previously had this problem (site SD using MySql) and two high-access sites that didn't (sites AB and MR using MDB) ("high-access" is a relative term - they are all fairly low by some standards).
This new layer, a replacement for my aging security traps, accesses a MySql database before anything on the actual sites gets parsed. The MySql access replaces a text file read on a previous version of the traps (which are still running error-free on many other sites). All the new Trap sites now exhibit the 0115 problem, again infrequently but more frequently on two of the high-access sites, probably because there are more pages to react.
Another "site" is used as a Control Panel to read/write the MySql database and that failed as much as any of the sites. I thought I'd fixed the problem in this CP but succeeded only in reducing the incidence; however this did suggest a possible reason: excess createobject calls.
One of the instances (MR) has a higher failure rate BUT the page that features most comprises (apart from the MySql security hit) only a single read of a text file (using createobject). That's just two Creates in a single page of minimal external objects.
The faults seem to occur at times I would expect high-ish activity on the server on AB and MR sites.
The CP failure seems to happen only at times when other sites throw up an error (ie when the server is busy), and yet it comprises a single page with a single Create and half a dozen reads of a single table at a rate of about one page per 30 seconds tops (I'm requesting the page through a browser). The latest failure of this CP page, which I'm able to run with a lot of tracing lines, shows the failure happens on the first Create/Open (ADODB.Connection and dataconn.Open). I have seen failures at other times later in the sequence than this.
What it is not: missing form names (this is a known 0115 report): most affected pages are not forms driven and ALL fields have names.
No database field has a Reserved name (nor do the forms).
It may be session names (another known 0115 report) but I doubt it: the MR text-read page has only a handful of them.
None of the other MS excuses seem to be relevant.
My impression is that there are too many objects created at certain times by the SERVER (I say this because failures include the minimalist CP page).
My GUESS is that at peak times the number of Creates (and their allied processing) has been increased by the extra Trap script beyond a boundary quantity for the SERVER (because it's using MySql not flat file).
Is this possible?
Is there a way to increase the number of objects available if it is?
Does anyone out there have any helpful ideas on this?
Please? :(
