DAO 3.6 Object Library moved down the list

[Guest]

Hi all you smart people.
I have an Access 2003 database. We have a number of users that have Access
installed and we have a handful of users that are running this database using
the run-time deployment. This has been working fine since mid-summer. Last
week one of the run-time users was using the database for a while, then all
of the sudden it went belly up, and nobody could get in. The error was "type
mismatch" and they couldn't get out of it - ended up restoring the previous
night's backup. Then last week it happened again, by the same user. I did
some testing and found that the reference to DAO 3.6 Object Library was no
longer in the place it was originally - instead of at position 3 in the
reference list, it was at the bottom - still checked however. All I did was
move it back into place, re-compile, and we're running again.

I saw on another post to preface my recordset statements with DAO, and I
will do that, but I also would like to know why the reference got moved and
if there's something I should do about that.

Thanks in advance.

 

[Douglas J. Steele]

I've not heard of the references reordering themselves. I'd check whether
that user was trying to fix things him/herself.

However, from what you've described, I'd hazard a guess that you haven't
split the application into a front-end (containing the queries, forms,
reports, macros and modules), linked to a back-end (containing the tables
and relations). Only the back-end should be on the server: each user should
have his/her own copy of the front-end, ideally on his/her hard drive. With
a set up like that, at least you wouldn't have to worry about one user
impacting the others (and you likely wouldn't have had to restore from
backup)

 

[Tony Toews [MVP]]

I have an Access 2003 database. We have a number of users that have Access
installed and we have a handful of users that are running this database using
the run-time deployment. This has been working fine since mid-summer. Last
week one of the run-time users was using the database for a while, then all
of the sudden it went belly up, and nobody could get in. The error was "type
mismatch" and they couldn't get out of it - ended up restoring the previous
night's backup. Then last week it happened again, by the same user. I did
some testing and found that the reference to DAO 3.6 Object Library was no
longer in the place it was originally - instead of at position 3 in the
reference list, it was at the bottom - still checked however. All I did was
move it back into place, re-compile, and we're running again.

I saw on another post to preface my recordset statements with DAO, and I
will do that, but I also would like to know why the reference got moved and
if there's something I should do about that.

Are you using ADO? If not then remove the ADO reference completely
and that should take care of any ordering problems in the reference
list.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/

 

[Brent Spaulding \(datAdrenaline\)]

I suppose your reference COULD move with a C & R ... but it is my guess
someone moved it down the priority list. The reason you got the error is
because an other library (probably ADO as Tony suggests) is in use and had a
higher priority than DAO .. plus you IMPLICITLY declared your object ...

Dim rst As Recordset

With a statement like the above, VBA will find the FIRST object from the
object libraries that are referenced that match the word "Recordset" ... so
if the ADO object library is HIGHER on the list (thus greater priority) than
DAO, the object variable rst is being flaged as an ADO Recordset. That is
why its good to fully qualify your DAO and ADO objects ...

Dim rstD As DAO.Recordset
Dim rstA As ADODB.Recordset

I would encourage you to place the library identifier you need in front of
all DAO and ADO objects. Then the order of the reference is not
critical.... although I put the most used ones near the top of the list.