Vista and 2007 - DAO library work, but shows unchecked in References

[timmg]

Situation: Single .mdb developed in A97 last Centurary, very stable
and minimal enhancements in the last 3 years. Previously converted to
A2000

Test conversion to 2007 on Vista works except for:

1) one subform refused to show data. Opening parent form in desing
view and looking at it disaprovingly before closing and save solved
problem. Not sure why

2) Tools-References shows DAO 3.6 library as unchecked, but checking
it gets "another reference with that name exists." Compile crashed on
"Me.Bookmar k." Decompile seems to solve the problem.

I checked a few resources, but haven't seen this problem mentioned.
Haven't tried reregistering the .dll.

Advise, warnings, sage ponderings?

Tim Mills-Groninger

[Allen Browne]

Hi Tim.

Suggestions in-line.

--
Allen Browne - Microsoft MVP. Perth, Western Australia
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.

"timmg" <tm************ *@gmail.comwrot e in message
news:6d******** *************** ***********@m3g 2000hsc.googleg roups.com...

Situation: Single .mdb developed in A97 last Centurary, very stable
and minimal enhancements in the last 3 years. Previously converted
to A2000

Test conversion to 2007 on Vista works except for:

1) one subform refused to show data. Opening parent form in
design view and looking at it disaprovingly before closing and
save solved problem. Not sure why

There is a difference of behavior if a form has a saved filter, and its
FilterOnLoad property is Yes. Whatever you did, it may have cleared the
Filter.

2) Tools-References shows DAO 3.6 library as unchecked, but checking
it gets "another reference with that name exists."

Assuming you are logged on as a local computer administrator, you might
unregister dao360.dll, and reregister it. You probably know how to do that
with regsvr32, but the command lines are listed here:
http://allenbrowne.com/ser-38.html

This is assuming that you converted it to an MDB. If you converted it to an
ACCDB, you should use the "Office 12 Access database engine Objects library"
(acedao.dll), not DAO 3.6.

Compile crashed on "Me.Bookmar k."
Decompile seems to solve the problem.

Very common. Bad binaries (i.e. the issue a decompile solves) is such an
issue that you need to do that automatically when you switch versions.

I checked a few resources, but haven't seen this problem mentioned.
Haven't tried reregistering the .dll.

Advise, warnings, sage ponderings?

In case you have't read this yet:
http://allenbrowne.com/Access2007.html

[timmg]

On Jun 5, 9:30*am, "Allen Browne" <AllenBro...@Se eSig.Invalidwro te:
...

Suggestions in-line.

...

>

...

1) one subform refused to show data. *Opening parent form in
design view and looking at it disaprovingly before closing and
save solved problem. *Not sure why

There is a difference of behavior if a form has a saved filter, and its
FilterOnLoad property is Yes. Whatever you did, it may have cleared the
Filter.

Ah, going to design and resaving proabably cleared the filter. Most
of the forms open to the full table source and are filtered by a
combobox - if they're called by another form to show detail they'll
get filtered with a where clause. Good call, and likely a repeatable
solution.

>

2) Tools-References shows DAO 3.6 library as unchecked, but checking
it gets "another reference with that name exists."

Assuming you are logged on as a local computer administrator, you might
unregister dao360.dll, and reregister it. You probably know how to do that
with regsvr32, but the command lines are listed here:
* *http://allenbrowne.com/ser-38.html

This is assuming that you converted it to an MDB. If you converted it to an
ACCDB, you should use the "Office 12 Access database engine Objects library"
(acedao.dll), not DAO 3.6.

D'oh, of course. They let their network consultant do the intitial
conversion, which wat to ACCDB. That explains the conflict.

>

Compile crashed on "Me.Bookmar k."
Decompile seems to solve the problem.

Very common. Bad binaries (i.e. the issue a decompile solves) is such an
issue that you need to do that automatically when you switch versions.

I might go ahead and decompile the 2000 version prior to the final
conversion. All told I had it working in 30 minutes, and next time I
can do it in 20. Maybe the network person will allow me in via
terminal services.

>

I checked a few resources, but haven't seen this problem mentioned.
Haven't tried reregistering the .dll.

Advise, warnings, sage ponderings?

In case you have't read this yet:
* *http://allenbrowne.com/Access2007.html

didn't look today, but have in the past. As always, top notch stuff.

Thanks again for this and the other excellent you've provided. (per
the other thread on thanks or no thanks)

Tim Mills-Groninger