AS 2000 DSO loses connection

We use DSO with ASP.NET 1.1 via COM layer through interop. However, sometimes after awhile the connection can no longer be established. The error occurs somewhere in the following code, most likely the first line:

dsoServer.Connect ServerName
Set m_dsoServer = dsoServer

If m_dsoServer.MDStores.Find(mvarDBName) Then
Set m_dsoDatabase = m_dsoServer.MDStores(mvarDBName)
Else
' Dont do nothing for now
End If

The error reads: Error: Cannot connect to the repository.

Restarting IIS fixes this problem until it recurs. Any idea?

Thanks,
Boris Zakharin

Calling DSO from ASP.NET is not really a supported scenario :(

Is your repository in Access or migrated to SQL Server ?

|||Access|||Then please migrate it to SQL Server. There are plenty of benefits in doing so, and it also might help in your scenario, although as I already mentioned, it is not supported one.|||Could you point me to where it says that using DSO from ASP.NET is not supported?
I have found at least one KB article talking about how to do this very thing (http://support.microsoft.com/kb/823066). Does this not mean that it is in fact supported?|||It's more like there is no documentation which states that DSO is supported from ASP.NET. (And up to AS2000 it wasn't supported even for ASP.) Microsoft doesn't ship PIA for DSO, so using DSO from any .NET application is not supported, although technically you can build interop assembly yourself. Remember, DSO was built in VB6 for VB6 programmers, before .NET was invented, and there are many potential issues around integration between the two.|||So, what is the supported way to access AS 2000 data from ASP.NET?|||In order to access data you should use ADOMD.NET. DSO is for the administrator operations.|||I assume things like creating a cube and changing a filter are considered administrative. We allow users to do that from our web application.|||

I am not sure what you mean by "changing a filter".

Creating cubes from web application is a loaded operation. You may want to consider migrating to AS2005, where you could either use AMO from ASP.NET or generate XMLA scripts directly.