Greetings. So, two years ago I customized a database to suit our office statistical needs. It's been working like a charm. I created it in 2003, but now our office is migrating to Windows 7 (MS Access 2010). 2010 will not open my 2003 version based on a 'MACAL.OCX' error. I think I've discovered this to be an issue with Calendar control vs. Date Picker. Nonetheless, if I can just delete everything to do with my Calendar, which is on my switchboard form...I think 2010 can then open it. HELP!
Calendar Control vs. Date Picker (1 Viewer)
- Thread starter skydiver
- Start date
boblarson
Smeghead
- Local time
- Today, 13:18
- Joined
- Jan 12, 2001
- Messages
- 32,059
Yes, MSCAL.ocx was deprecated in 2010. So, what you can do is to HOLD your shift key down until the database has opened, go to each form and delete that control. Save them. Then go to the VBA window and to TOOLS > REFERENCES and make sure there is no reference set for that control. And then, while still in the VBA window, click on DEBUG > COMPILE and see if any errors pop up. If so go fix them. Then you should be able to move on from there.
Bingo Bob! That worked (Please excuse my excitement)!!!
Question. In REFERENCES, I've deselected the Calendar Control, however there is also a "Microsoft ActiveX Data Objects 2.1 Library" reference. Do I deselect this one as well or leave it alone?
Question. In REFERENCES, I've deselected the Calendar Control, however there is also a "Microsoft ActiveX Data Objects 2.1 Library" reference. Do I deselect this one as well or leave it alone?
ChrisO
Registered User.
- Local time
- Tomorrow, 06:18
- Joined
- Apr 30, 2003
- Messages
- 3,202
I have a different approach so this is what I do.
A reference is an external dependency which, if it serves no purpose, should be removed. A reference may not be required but it can still cause a problem if it is MISSING. It boils down to the ability to continue to operate in an unknown and, therefore, unstable environment.
If the environment is stable then there’s not much problem. But a stable environment can become unstable due to a version change, which is what happened here.
If the environment is unstable then all hell can break loose. If the environment is unknown then assume unstable.
Do until all references, which can be removed, are removed.
Make a backup of the original.
Delete the reference in the original.
(Work on the original, not the backup as is often suggested. The reason is that the original may be directory (positional) dependant and the backup may not be in the same directory as the original. Therefore, working on the backup may raise other errors which have nothing to do with references.)
Compile and test.
If all is okay then you are done with this reference.
If all is not okay then reinstate the last backup.
Next reference.
Loop
Done.
Optionally…
Late bind any code and remove the reference it required.
It has become particularly important, again after XP and Access 2003, to remove the reference to DAO. In the vast majority of situations a reference to DAO is not required. The version of DAO is generally not a problem (It can be if the old reference was ‘Microsoft 2.5/3.5 Compatibility Library’) but its location has changed.
Remove any ActiveX controls and replace with an Access native solution.
Until the environment is known to be stable explicitly call libraries in an unambiguous manner.
http://www.trigeminal.com/usenet/usenet026.asp?1033
This would be particularly important with a global error handler. The global error handler may run at any time and that means before the application is known to be stable.
Write code in such a way as to become immune to regional settings.
Write code in such a way as to become immune to natural language versions.
---
It boils down to producing a database, and writing code, as best be can, which is immune to uncontrollable dependencies both internal and external.
Chris.
A reference is an external dependency which, if it serves no purpose, should be removed. A reference may not be required but it can still cause a problem if it is MISSING. It boils down to the ability to continue to operate in an unknown and, therefore, unstable environment.
If the environment is stable then there’s not much problem. But a stable environment can become unstable due to a version change, which is what happened here.
If the environment is unstable then all hell can break loose. If the environment is unknown then assume unstable.
Do until all references, which can be removed, are removed.
Make a backup of the original.
Delete the reference in the original.
(Work on the original, not the backup as is often suggested. The reason is that the original may be directory (positional) dependant and the backup may not be in the same directory as the original. Therefore, working on the backup may raise other errors which have nothing to do with references.)
Compile and test.
If all is okay then you are done with this reference.
If all is not okay then reinstate the last backup.
Next reference.
Loop
Done.
Optionally…
Late bind any code and remove the reference it required.
It has become particularly important, again after XP and Access 2003, to remove the reference to DAO. In the vast majority of situations a reference to DAO is not required. The version of DAO is generally not a problem (It can be if the old reference was ‘Microsoft 2.5/3.5 Compatibility Library’) but its location has changed.
Remove any ActiveX controls and replace with an Access native solution.
Until the environment is known to be stable explicitly call libraries in an unambiguous manner.
http://www.trigeminal.com/usenet/usenet026.asp?1033
This would be particularly important with a global error handler. The global error handler may run at any time and that means before the application is known to be stable.
Write code in such a way as to become immune to regional settings.
Write code in such a way as to become immune to natural language versions.
---
It boils down to producing a database, and writing code, as best be can, which is immune to uncontrollable dependencies both internal and external.
Chris.
