Microsoft says they won't support my question since VB6 is no longer supported, I'm re-posting a digest version of what I posted there with a bit more clarity. I'm hoping someone can make suggestions which can bail me out here without requiring me to re-code the entire application which was not mine to start with.
I'm currently in the process of migrating applications from a Windows 2000 server to a Server 2003 or 2008 system because of corporate mandate. Because of the number of changes between Server 2000 and Server 2008, I am opting to migrate only as far as 2003 at this point.
Application uses a Classic ASP web-based front-end which instantiates VB6 DLL objects contained in an application-specific Component Services package which activates under the login context of a domain account. The DLLs connect to a SQL 2008 data source hosted on a Server 2008 system.
On our current Server 2000 system where the Classic ASP and Component Services is set up, all works fine. When attempting to set this up the same way on our Server 2003 system, a connection to the database will not work unless the DLL is activated outside of Component Services (i.e. Registered ONLY through REGSVR32). We cannot operate the data component outside of Component Services because some features need to use transactions and Component Service roles to function.
When the DLL is contained within a Component Services application, the following error occurs:
Err.number = 3001
Err.Source = ADODB.Command
Err.Description = Arguments are of the wrong type, are out of acceptable range, or are in conflict with one another.
Err.HelpContext = 1240641
Err.helpfile = C:\Windows\HELP\ADO270.CHM
When the DLL is registed by ONLY using REGSVR32 (and is not contained in Component Services), the above error does not occur.
Where Problems Occur
Below are relevant code snippets for both my calling Classic ASP page and the DLL's method code which is being executed. Bear in mind, setting the .ActiveConnection works when I register this using REGSVR32, but if I include this in a Component Services package, it fails.
Classic ASP code:
(Using double apostrophes in my VB code for comments in code below to preserve EE syntax hilighting)
Affected DLL Object code (Found within MyLogin project, NTLogin module):
Set Login = Server.CreateObject("MyLogin.NTLogin")
'' Removed irrelevant Login object properties which are set...
Set cn = Server.CreateObject("ADODB.Connection")
cn.ConnectionString = strMyConnectionString
If Err.number <> 0 Then
Response.Write ("Error opening database")
'' In this ASP page, this is where things fail:
Things I Have Tried
Public Sub GetUserInfo(ByVal cn As Variant)
'' (Irrelevant code removed)
Dim cmd As Command
Set cmd = New Command
'' The next line is where it blows up (when in Component Services)
'' or works (when simply registered with REGSVR32):
.ActiveConnection = cn
'' code at this point is not executed because it failed when setting
'' the Active Connection above.
Thinking there may have been references to MDAC 2.5 which needed updating to MDAC 2.8, I recompiled the DLLs.
Component Services on my Server 2003 system have had COM Security set up to allow Access and Launch permissions for all accounts I'm using (both Classic ASP users, impersonated Component Service user)
Things I Know
When the DLL is in Component Services, no connection attempt is even made. When registed using REGSVR32, it does connect and retreive data. This was verified using SQL Server Profiler which I used to monitor all connection activity.
Failure happens when we set the .ActiveConnection to the Variant "cn" which is passed from ASP code.
Do you have any advice or suggestions? Am I missing something here?