We have a Windows shared hosting plan and a relatively new ASP.NET application.  We have set up a number of VBScript files to run overnight via Task Scheduler, with several starting at the same time.  About once a month, the ASP.NET application stops and VBScripts fail because of a problem with the MSSQL database and we have to get Lunarpages support to "fix" the database.  We have not been able to figure out the problem and things have turned to examining the database usage of these VBScript files.

The errors in the Scheduler console output files are consistent and basically say that the database cannot be opened or accessed.  We have had at least one occasion when the VBScripts ran fine one hour but failed to run the next hour - and no changes were made to the system by a developer.  The last time we requested a change, we requested that the application automatically restarts every 3 hours.  We are not able to access the database via myLittleAdmin when the problem occurs.  This indicates that it is not an ASP.NET or a VBScript problem, but, a MSSQL problem.  Yes - we understand that the problem can be in our ASP.NET and/or VBScript code, but, we mean that we can start/run ASP.NET and VBScript but the problem is revealed only when the database is accessed.

We have yet to see an error indicating that something "just" happened and the result is a problem with the database.  That is, typically we would have a Scheduler console output file showing a VBScript running to completion without error but the next VBScript has an error upon the first access/usage of the database.

So.....

Does anyone have experience with multiple VBScript files simultaneously accessing the same MSSQL database and causing a problem with the database?

What sort of database/usage parameters (such as number of: database tables, table rows, open connections, rows retrieved in a query, queries per minute, etc.) would be "large" or "excessive" - possibly leading to problems?

How does Lunarpages compare to other hosts concerning these "parameters"?

It would seem that Lunarpages technical support is refusing to tell us the technical name of this problem and the technical name of what they are doing to fix the problem.

This is quite discouraging because it conveys one or more messages - intentionally or unintentional.  First, they don't know the answers.  If they don't have the technical expertise to diagnose the problem and then don't know what they did to fix the problem, that does not give us faith in their abilities as a MSSQL web host.  But, telling us that they don't know at least gives us a little bit more information - but they have not done that.  Second, they know but refuse to tell us.  They have not told us that they are doing this and we don't know why they would take this stance.  What can it hurt to tell us this information?  They have recommended that we upgrade to a dedicated server, but, have not provided any proof that would fix the problem.  If we knew what the problem was and/or what was done to fix the problem, it would allow us to make a more informed decision as to what type of web hosting service they we need - with Lunarpages or with another web host.  Third, it is not part of their responsibilities to tell us this information.  Fine, we will find and move to a web host that will tell us this information.  We are not asking them to diagnose and fix any coding that we have done.  We have simply asked them to tell us the name/term of what they find and the name/term of what they do to fix it.  If this information is proprietary and/or protected by law, then, tell us that.  If the issue is the time to tell us, they would have saved a lot more time by simply telling us at the very beginning.

Has anybody else had these types of issues with technical support?