Upgrading App From Access 2003 to 2010
I am planning to move a client app from Access 2003 to Access 2010. I am aware of some 2003 functionality that has changed/is different/isn't supported in 2010.
The first is the menu system. The application menu's developed in 2003 are for the most part supported in 2010 but no changes can be made to pop-up menu's. For this reason I thinks it would be best to recreate the menu's in 2010. Based on some prior EE advice I have purchased Ribbon Creator IDBE 2010 for that purpose.
The existing app has a shortcut menu available on all reports. One of the options is 'Export..." Once selected it allows the user to choose the type of export (Word, Excel, RTF etc..) they want. However, when the MDB is run under 2010, selecting this option gets an unsupported function message. I understand that in 2010 the exports are more specific and I will need to create a new shortcut menu with 'Export to Word', 'Export to Excel' etc... I have started working on these menus and have some created.
I also learned that these new menu's are not 'resident' in 2010 and have to be loaded at start up to make them available to the user.
I'm asking those of you that have gone thru the 2003 to 2010 process prior to me to identify other functionality or commands that work differently, or not at all in 2010. Perhaps even areas where the answer is 'The 2003 command/function works in 2010 but can be improved using new features of functionality available in 2010.
I realize there is no one correct answer to this post and will will award the point among helpful responses.
The first is the menu system. The application menu's developed in 2003 are for the most part supported in 2010 but no changes can be made to pop-up menu's. For this reason I thinks it would be best to recreate the menu's in 2010. Based on some prior EE advice I have purchased Ribbon Creator IDBE 2010 for that purpose.
The existing app has a shortcut menu available on all reports. One of the options is 'Export..." Once selected it allows the user to choose the type of export (Word, Excel, RTF etc..) they want. However, when the MDB is run under 2010, selecting this option gets an unsupported function message. I understand that in 2010 the exports are more specific and I will need to create a new shortcut menu with 'Export to Word', 'Export to Excel' etc... I have started working on these menus and have some created.
I also learned that these new menu's are not 'resident' in 2010 and have to be loaded at start up to make them available to the user.
I'm asking those of you that have gone thru the 2003 to 2010 process prior to me to identify other functionality or commands that work differently, or not at all in 2010. Perhaps even areas where the answer is 'The 2003 command/function works in 2010 but can be improved using new features of functionality available in 2010.
I realize there is no one correct answer to this post and will will award the point among helpful responses.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
DatabaseMX (Joe Anderson - Former Microsoft Access MVP)
:-)
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
LOL @mx
Actually, you can just put it in the same folder as your app...
I tried that.
Without the registry settings it doesn't work for me. YMMV
One of the best things that ever happened to the Access UI ... infinitely more flexible that the old pane. And ... Groups are now finally useful.
With 159 tables, 496 queries, 170 forms, 158 reports, and 50 modules, a flat file listing is pretty much useless. If I ever leave A2003 for good, I'll get around to coding the replacement form for the Database Window -- because the Nav Pain and the Metro UI share a common failing -- that people will search by typing the first few characters. I depend upon seeing items in context. A context that has been willfully removed.
It works for you. It doesn't work for me.
Actually, you can just put it in the same folder as your app...
I tried that.
Without the registry settings it doesn't work for me. YMMV
One of the best things that ever happened to the Access UI ... infinitely more flexible that the old pane. And ... Groups are now finally useful.
With 159 tables, 496 queries, 170 forms, 158 reports, and 50 modules, a flat file listing is pretty much useless. If I ever leave A2003 for good, I'll get around to coding the replacement form for the Database Window -- because the Nav Pain and the Metro UI share a common failing -- that people will search by typing the first few characters. I depend upon seeing items in context. A context that has been willfully removed.
It works for you. It doesn't work for me.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
Thanks to all for the comments.
Yes the legacy 2003 mdb's are split into data, which resides on the server and procedures (MDE), which resides on the user machines mdb's.
I use Sagekey 2003 for distribution of the existing 2003 application and have purchased Sagekey 2010 for use on the 2010 apps.
Nick67 mentioned the trust center requirement. I was concentrating on the application and hadn't thought about the trust center issue on deployments. Could you please provide more information about how this is set up on user machines?
Yes the legacy 2003 mdb's are split into data, which resides on the server and procedures (MDE), which resides on the user machines mdb's.
I use Sagekey 2003 for distribution of the existing 2003 application and have purchased Sagekey 2010 for use on the 2010 apps.
Nick67 mentioned the trust center requirement. I was concentrating on the application and hadn't thought about the trust center issue on deployments. Could you please provide more information about how this is set up on user machines?
It can be hacked into the registry in whatever fashion suits:
This to permit a network location
[HKEY_CURRENT_USER\Softwar
"AllowNetworkLocations"=dw
This for each permitted path, starting at location zero
Local path
[HKEY_CURRENT_USER\Softwar
"Path"="DriveLetter:\\fold
"AllowSubfolders"=dword:00
"Description"=""
"Date"="28/03/2013 9:41 AM"
Network path
[HKEY_CURRENT_USER\Softwar
"Path"="\\\\server\\share\
"AllowSubfolders"=dword:00
"Description"=""
"Date"="28/03/2013 9:41 AM"
I got tired of putting them in.
Now a double click of a .reg file does it.
Access 2013 is version 15.0, that's the only change
Access 2007, God help you, is version 12.0
You may be able to push it out via GPO or login scripts.
VBA is a chicken-and-egg problem. How do you use VBA to update the registry when the registry needs to be updated to run the VBA.
This to permit a network location
[HKEY_CURRENT_USER\Softwar
"AllowNetworkLocations"=dw
This for each permitted path, starting at location zero
Local path
[HKEY_CURRENT_USER\Softwar
"Path"="DriveLetter:\\fold
"AllowSubfolders"=dword:00
"Description"=""
"Date"="28/03/2013 9:41 AM"
Network path
[HKEY_CURRENT_USER\Softwar
"Path"="\\\\server\\share\
"AllowSubfolders"=dword:00
"Description"=""
"Date"="28/03/2013 9:41 AM"
I got tired of putting them in.
Now a double click of a .reg file does it.
Access 2013 is version 15.0, that's the only change
Access 2007, God help you, is version 12.0
You may be able to push it out via GPO or login scripts.
VBA is a chicken-and-egg problem. How do you use VBA to update the registry when the registry needs to be updated to run the VBA.
ASKER
Thank You