Run-time error '-2141024770' 2

[shallman]

I have an Access 2002, SP1 application that runs fine on 4 PC's, all running either Win2k and WinXP Professional. I moved the application another PC running WinXP Professional also with Access 2002, SP1 and now one of the forms that looks up a record in a table gets:

Run-time error '-2141024770 (8007007e)'
Method 'Rcordset' of object '_Form_Enter_Enter Funds' failed.

The application is using ADO 2.5 and not DAO, all the PC's have the same 'References' selected in the VB Editor under Tools. The line of code that causes the error is:

Me.Recordset.FindFirst "[AccountID] = " & enteredID

If I move the same mdb file back to one of the other PC's, it works fine.

Any ideas?
Thanks

 

[RoyVidar]

Hi!

I'm not a 100% sure on this dare do some guessing.

I think you might have a rest of the routine looking approx like this:

[tt]dim rs as object
set rs=me.recordset.clone[/tt]
...then your code follows.

I'm working mainly with ADO myself, but one does have to consider that recordsets from forms (perhaps with (this) one possible exception) are DAO.

The .findfirst method is a DAO method, requiring a DAO recordset, so like it or not, you're still using DAO, even if it's thru late binding;-) (corresponding method in ADO is .find). Thing is (and this is the reason I suggested what might be the rest of your code) that browsing the help files, I found that using me.recordset might produce either a dao or a ado recordset, but I'm not sure what triggers which type of recordset is returned.

I suspect that all the rest of you'r apps, are returning DAO, but in this application, ADO is returned, and causing the error, because .findfirst isn't a ADO method.

You might check it though, with;

[tt]if typeof rs is dao.recordset then
' bla bla
elseif typeof rs is adodb.recodset then
' more bla bla
end if[/tt] (code from help files, haven't tried it)

How to avoid it?

I think making sure you get a DAO recordset might be the way to go. Checking the DAO library, declaring the recordset as DAO, AND - in stead of using the clone method of me.recordset (which I suspect is why you on one machine probably are getting ADO), use me.recordsetclone, which as far as I've been able to establish, is a DAO recordset.

HTH Roy-Vidar

 

[shallman]

Roy-Vidar,

Thanks for your reply.

I think you may be right in that I may be mixing DAO and ADO types together and I may be more confused than ever.

I assumed I was using only ADO for the 2 following reasons:

1) I have the "ActiveX Data Object 2.5 Library" selected under 'References' and I do NOT have the "DAO 3.6 Object Library" selected.

2) If I put this declaration in any of my procedures:

Dim rs As dao.Recordset

I get a "Compile Error, user defined type not defined", which I though proved the DAO Library was not available. However, I use:

Dim rs As ADODB.Recordset and
rs.Open blah, blah, blah, ....
etc.

throughout my app successfully.


I do not have

dim rs as object
set rs=me.recordset.clone

anywhere in my project as you suggested I may, nor do I do anything with recordset.clone. I thought if the DAO Library was not selected and the ADO was (which is the default in Access 2000 and later) that behind the scenes Access was using ADO with the forms, DoCmd's, etc. and converting the DAO calls like .findfirst to their ADO equivelents behind the scenes. Perhaps the bound forms I use are opening DAO recordsets without the DAO library being selected and then I am dong the equivelent of the recordset.clone with ADO?

Do I sound completely lost?

Thanks,
Scott (SHallman)

 

[RoyVidar]

I hope I didn't come thru as suggesting you where mixing ADO and DAO, but I was (and still am) kind of wondering or guessing that maybe Access was.

Could you just try:
either (ADO)
[tt]Me.Recordset.Find "[AccountID] = " & enteredID[/tt]

(if this works, then I'd believe this PC was returning ADO and the others DAO, which might be resolved with the if statement in previous post)

or (DAO-1)
[tt]Me.RecordsetClone.FindFirst "[AccountID] = " & enteredID[/tt]

or (DAO-2)
[tt]dim rs as object
set rs=me.recordsetclone
rs.FindFirst "[AccountID] = " & enteredID
' and then perhaps
me.bookmark=rs.bookmark ' if that's what you do[/tt]

and see if any of these works?

(I'm not able to reproduce the errors it here)

If you should sound lost, then I'm probably beyond lost;-)

Roy-Vidar

 

[shallman]

Interesting enough, I get the exact same error after making the code change you suggested.

---------------
Private Sub AccountID_Exit(Cancel As Integer)
Dim X As Integer
enteredID = Str(Val(Me.AccountID))
If Me.Dirty Then
DoCmd.RunCommand acCmdUndo 'Clear event stack so cursor returns to same control and not follow tab order.
End If
DoCmd.Hourglass True
Me.Recordset.Find "[AccountID] = " & enteredID
' Me.Recordset.FindFirst "[AccountID] = " & enteredID
DoCmd.Hourglass False
If Recordset.NoMatch = True Then
MsgBox (" Account ID" & enteredID & " Not Found &quot
Cancel = True
End If
End Sub
--------------------------

When I put the same code changes on the other PC's that work with this app, I get a "Run Time error 438, Object doesn't support this property or method". That shows that DAO is being used with my forms as you previously suggested.

I also found that when I am in the VB Editor editing any code related to this project and I type "Me.", instead of getting the coding help that normally pops up, the period never appears, the editor hangs for a few seconds and I get the proverbial error "Microsoft Access has encountered a problem and needs to close. We are sorry for the inconvenience. Bla, Bla ... Do you want to send and error report to Micosoft".

I have un-installed and re-installed Access with no change. I am going to re-spin the XP CD next. I will let you know if that helps.

Thanks,
Scott

 

[RoyVidar]

hmmm...

The last thing you bring up might be a corruption issue, have you tried decompile?

(Close all instances of Access, choose Start | Run and enter:
[tt]msaccess /decompile c:\fullpath\name.mdb[/tt]
Close the db, open it again, open a module and compile)

On the initial problem, I'm stumped. The error message should indicate that Access doesn't recognize either the recordset property or the findfirst method. Where I've encountered those, I've used somes variations of my above mentioned snippets to get past them. I also provided rather similar advice in a related thread, there too not working.

Just one thought, have you tried to create the database on the "faulty" PC? Creating a new database, import all objects from your current database...

The only other difference I've been able to spot between my setup, yours and the before mentioned thread, is that I still use ADO 2.1, but I don't think that should produce such errors.

Hopefully other memebers might share tips and solutions that will work.

Sorry I couldn't be of assistance.

Roy-Vidar

 

[shallman]

I have resolved this issue!

I found that when I go into "Relationship" under "Tools" in the VB editor and selected "Microsoft DAO 3.6 Library", I would get an error "C:\Windows\System32\DAO360.dll" not found. I did the same on the working PC's, linked to the same library and it linked to "C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.dll" with no problem.

I searched the hard drive for this module on the broken PC and only found this module in "C:\i386" directory

I ran the XP Office CD and did a repair installation and the DAO360.dll file was then installed and registered properly. I then went back to "Relationships" on the broken PC, checked the "Microsoft DAO 3.6 Library" and browsed to the "C:\Program Files\Common Files\Microsoft Shared\DAO\DAO360.dll" and all worked.

I found this similiar description of the problem on the web, apparently sometimes effecting WinXP installs.

http://www.pqsystems.com/kb/question.php?qstId=424

It appears that even though I don't use DAO and don't have the "Relationship" selected, Access does use it.

Thanks for all the help.

 

[RoyVidar]

Glad you found out!

Don't think I'd been able to even think in that direction. Have a star for finding this out!

Roy-Vidar

 

[shallman]

RoyVidar,
Here is a star for you for helping me better understand recordset issues!