"Error in Loading DLL" at currentproject.connection on different machine

R

Rico

Hello,

I have a project that I've been handed and I'm in the midst of setting up a
development environment. The program is written in Access 2002, on a Win2k
Server using SQL Server 2000 as the back end.

I have replicated the environment (Win2k server, Access 2002 and SQL Server
2000). When I run the FE in the development environment, I get "Error in
loading DLL" at a point where the form has the line
"rstLoanList.ActiveConnection = CurrentProject.Connection". This works in
the production version. There are no broken references or anything. I've
pasted the code at the end of this message, but I don't think there is
anything in the code that is breaking this.

Any help would be greatly appreciated.

Thanks!

Private Sub cmdUpdate_Click()

Dim stDocName As String

Dim rstLoanList As ADODB.Recordset
Set rstLoanList = New ADODB.Recordset

'rstLoanList.ActiveConnection = CurrentProject.Connection
rstLoanList.ActiveConnection = CurrentProject.Connection
rstLoanList.CursorType = adOpenKeyset
rstLoanList.LockType = adLockOptimistic

rstLoanList.Open "Select * from LoanList where OverPayment > 0"

Do Until rstLoanList.EOF

Me![txtClientID] = ""
Me![txtLastName] = ""
Me![txtFirstName] = ""
Me![txtInvNumber] = 0
Me![txtOverPayment] = 0
Me![txtOverPaymentDate] = ""

Me![txtClientID] = rstLoanList![ClientID]
Me![txtLastName] = rstLoanList![LastName]
Me![txtFirstName] = rstLoanList![FirstName]
Me![txtInvNumber] = rstLoanList![InvNumber]
Me![txtOverPayment] = rstLoanList![OverPayment]
Me![txtOverPaymentDate] = rstLoanList![OverPaymentDate]

stDocName = "qryCreateOPFromLoanListTable"

DoCmd.SetWarnings (False)
DoCmd.OpenQuery stDocName, acNormal, acEdit
DoCmd.SetWarnings (True)

rstLoanList.MoveNext
Loop

rstLoanList.Close
Set rstLoanList = Nothing
 
G

Guest

Hi Rico,

If you have no broken references (ie. marked as MISSING), then try
refreshing your references collection. See this article for more details:

Solving Problems with Library References (Allen Browne)
http://allenbrowne.com/ser-38.html

If that does not fix the problem, then try re-registering the ADO Library on
the development PC. Click on Start > Run, and paste the following command
into the box:

Regsvr32.exe "C:\Program Files\Common Files\system\ado\Msado15.dll"

and, just for good measure:
Regsvr32.exe "C:\Program Files\Common Files\Microsoft Shared\DAO\Dao360.dll"

Still not working? Try the MDAC Component Checker utility:
http://support.microsoft.com/?id=307255



Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________
 
R

Rico

Thanks Tom, re-registering the ADO library did the trick.

Rick


Tom Wickerath said:
Hi Rico,

If you have no broken references (ie. marked as MISSING), then try
refreshing your references collection. See this article for more details:

Solving Problems with Library References (Allen Browne)
http://allenbrowne.com/ser-38.html

If that does not fix the problem, then try re-registering the ADO Library on
the development PC. Click on Start > Run, and paste the following command
into the box:

Regsvr32.exe "C:\Program Files\Common Files\system\ado\Msado15.dll"

and, just for good measure:
Regsvr32.exe "C:\Program Files\Common Files\Microsoft Shared\DAO\Dao360.dll"

Still not working? Try the MDAC Component Checker utility:
http://support.microsoft.com/?id=307255



Tom Wickerath
Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________


Rico said:
Hello,

I have a project that I've been handed and I'm in the midst of setting up a
development environment. The program is written in Access 2002, on a Win2k
Server using SQL Server 2000 as the back end.

I have replicated the environment (Win2k server, Access 2002 and SQL Server
2000). When I run the FE in the development environment, I get "Error in
loading DLL" at a point where the form has the line
"rstLoanList.ActiveConnection = CurrentProject.Connection". This works in
the production version. There are no broken references or anything. I've
pasted the code at the end of this message, but I don't think there is
anything in the code that is breaking this.

Any help would be greatly appreciated.

Thanks!

Private Sub cmdUpdate_Click()

Dim stDocName As String

Dim rstLoanList As ADODB.Recordset
Set rstLoanList = New ADODB.Recordset

'rstLoanList.ActiveConnection = CurrentProject.Connection
rstLoanList.ActiveConnection = CurrentProject.Connection
rstLoanList.CursorType = adOpenKeyset
rstLoanList.LockType = adLockOptimistic

rstLoanList.Open "Select * from LoanList where OverPayment > 0"

Do Until rstLoanList.EOF

Me![txtClientID] = ""
Me![txtLastName] = ""
Me![txtFirstName] = ""
Me![txtInvNumber] = 0
Me![txtOverPayment] = 0
Me![txtOverPaymentDate] = ""

Me![txtClientID] = rstLoanList![ClientID]
Me![txtLastName] = rstLoanList![LastName]
Me![txtFirstName] = rstLoanList![FirstName]
Me![txtInvNumber] = rstLoanList![InvNumber]
Me![txtOverPayment] = rstLoanList![OverPayment]
Me![txtOverPaymentDate] = rstLoanList![OverPaymentDate]

stDocName = "qryCreateOPFromLoanListTable"

DoCmd.SetWarnings (False)
DoCmd.OpenQuery stDocName, acNormal, acEdit
DoCmd.SetWarnings (True)

rstLoanList.MoveNext
Loop

rstLoanList.Close
Set rstLoanList = Nothing
Click to expand...
Click to expand...
 
D

Dirk Goldgar

Rico said:
rstLoanList.ActiveConnection = CurrentProject.Connection
Click to expand...

Rico -

I'm glad to read that you solved the bug that prompted your post. As a
completely side issue, I think the above line would be better as

Set rstLoanList.ActiveConnection = CurrentProject.Connection

Using the "Set" keyword will assign the current project's active
connection object to the recordset object's ActiveConnection property.
Without that keyword, another, separate connection will be created and
opened, using the same connection string as CurrentProject.Connection.
It will still work -- as apparently it does -- but it won't be as
efficient.
 
Top