asked on Microsoft Access 2007 Deployment Does Not Work
I have prepared a full database system which my client wants as a runtime. I downloaded the tools set containing the Package Solution Wizard and after some time was able to use it confidently.
I beg your patience as the solutions offered were laboriously attempted, fairly complicated, and did not yield a satisfactory result.
This deployment tool only allows one database at a time, so I created one installation package for my front-end, with included files such as a spreadsheet which is an import sample. An Excel license is expected on the client machine. Another package was created for the back-end, and one more for the configuration database.
Installation went smoothly.
I ensured that my Microsoft Office Service Packs were up to date.
On opening the system and logging in, my relink code worked, and I had the interface in front of me. It consists of a tabbed control as my menu, with some tabs having buttons only, some having forms with subforms on them. Only one simple form without subforms, shows correctly.
However all those with subforms were blank. All controls were not visible. (Nothing to do with coding). Tabs with buttons only, were visible. On clicking any button that runs core VBA functions, such as string functions, there were errors such as you see in the "Errors" tab in the attached.
One solution offered to me was that installation references can be in the wrong order (although the development database's are correct). However that cannot be manipulated in a runtime (.accdr) file.
I tried installing to an office 2000, 2003 and 2007 machine which have no Access pre-installed.
Further, permissions was proposed as an issue. Using the Workgroup Administrator, I attempted to assign myself full control as an Administrator on the development front-end. On going into Properties of its shortcut, and clicking "Advanced", brought me to the option "Run as Administrator". But that was greyed out. However I regenerated the packages, reinstalled, and had the same result.
The core references I used were:
-VBA
-MS Acc 12.0 OLB
-OLE Aut
-MSO 12.0 Acc DB Engine Objects Lib
References I included were:
-Microsoft Windows Common Controls 6.0 (SP6)
-Microsoft Office 12.0 Object Library
-Microsoft Excel 12.0 Object Library
I beg your patience as the solutions offered were laboriously attempted, fairly complicated, and did not yield a satisfactory result.
This deployment tool only allows one database at a time, so I created one installation package for my front-end, with included files such as a spreadsheet which is an import sample. An Excel license is expected on the client machine. Another package was created for the back-end, and one more for the configuration database.
Installation went smoothly.
I ensured that my Microsoft Office Service Packs were up to date.
On opening the system and logging in, my relink code worked, and I had the interface in front of me. It consists of a tabbed control as my menu, with some tabs having buttons only, some having forms with subforms on them. Only one simple form without subforms, shows correctly.
However all those with subforms were blank. All controls were not visible. (Nothing to do with coding). Tabs with buttons only, were visible. On clicking any button that runs core VBA functions, such as string functions, there were errors such as you see in the "Errors" tab in the attached.
One solution offered to me was that installation references can be in the wrong order (although the development database's are correct). However that cannot be manipulated in a runtime (.accdr) file.
I tried installing to an office 2000, 2003 and 2007 machine which have no Access pre-installed.
Further, permissions was proposed as an issue. Using the Workgroup Administrator, I attempted to assign myself full control as an Administrator on the development front-end. On going into Properties of its shortcut, and clicking "Advanced", brought me to the option "Run as Administrator". But that was greyed out. However I regenerated the packages, reinstalled, and had the same result.
The core references I used were:
-VBA
-MS Acc 12.0 OLB
-OLE Aut
-MSO 12.0 Acc DB Engine Objects Lib
References I included were:
-Microsoft Windows Common Controls 6.0 (SP6)
-Microsoft Office 12.0 Object Library
-Microsoft Excel 12.0 Object Library
Microsoft Legacy OSMicrosoft ApplicationsMicrosoft Development
Last Comment
Scott McDaniel (EE MVE )
You mention something that was attached, but there are not attachments to the question.
Are you certain the -Microsoft Windows Common Controls 6.0 (SP6) exists on the target system? These are not automatically installed, especially with newer machines. In fact, you should take steps to remove those controls, and use native Access controls instead. You'll find nothing but troubles moving forward with those, especially as more and more people transition over to 64 bit.
Microsoft Office 12.0 Object Library
Is Office installed on the target machine? You mention the Runtime, so it's not clear whether your target machine has a full, valid Office installation
Are you certain the -Microsoft Windows Common Controls 6.0 (SP6) exists on the target system? These are not automatically installed, especially with newer machines. In fact, you should take steps to remove those controls, and use native Access controls instead. You'll find nothing but troubles moving forward with those, especially as more and more people transition over to 64 bit.
Microsoft Office 12.0 Object Library
Is Office installed on the target machine? You mention the Runtime, so it's not clear whether your target machine has a full, valid Office installation
Invest in SageKey Deployment, works without a hitch everytime!
Sagekey is great, but it's not going to install references unless you tell it to do so.
Hi,
the Common Controls library had some issues because of a defect update from Microsoft in August last year which made them unavailable after this update. That issue is solved since beginning of this year so there is no need to replace them, they work without problems also in Windows 7 64 Bit. Unfortunately there is no real replacement so you do not have a chance to replace them with Access native controls, i.e. there is no Treeview control in Access.
Yes, the reference order can be a problem but it would be the same in the full and the runtime version of Access and only if you do not use the full qualified name for objects. You should always declare an object with the full name to avoid that. I.e., use "DAO.Recordset" and not "Recordset" because if you also use ADO then there is also a "Recordset" object there so the order in the references is the one which decides which one is used. If you declare it also with "ADODB.Recordset" there will be no problem.
The references will automatically adjusted by Windows/Office if you use an older one and the machine has a newer one. So if you develop something with the Office 12 library (O2007) and the machine has Office 2010 installed it will automatically use the Office 14 library - but not in the other direction. So if you develop something with the Office12 library in the references and try to run it on a machine with an older Office that will not work. So if you have different versions at the client side you are normally forced to develop with the oldest available version or recommend the client to install the same version on all clients (which should normally be the case...).
Moreover, you should no longer use the Access security system because it was officially removed in A2007, although it can be used here for compatibility reasons. In A2010 it is no longer available. You should consider to use a SQL Server as backend to which you can migrate easily and if you want you can install the Express version which doesn't cost anything (not more than a server which runs it). The security model of SQL Server is much better than Access ever was.
I personally use InnoSetup to create installers. This one is free and very comfortable and it produces very small installers.
Cheers,
Christian
the Common Controls library had some issues because of a defect update from Microsoft in August last year which made them unavailable after this update. That issue is solved since beginning of this year so there is no need to replace them, they work without problems also in Windows 7 64 Bit. Unfortunately there is no real replacement so you do not have a chance to replace them with Access native controls, i.e. there is no Treeview control in Access.
Yes, the reference order can be a problem but it would be the same in the full and the runtime version of Access and only if you do not use the full qualified name for objects. You should always declare an object with the full name to avoid that. I.e., use "DAO.Recordset" and not "Recordset" because if you also use ADO then there is also a "Recordset" object there so the order in the references is the one which decides which one is used. If you declare it also with "ADODB.Recordset" there will be no problem.
The references will automatically adjusted by Windows/Office if you use an older one and the machine has a newer one. So if you develop something with the Office 12 library (O2007) and the machine has Office 2010 installed it will automatically use the Office 14 library - but not in the other direction. So if you develop something with the Office12 library in the references and try to run it on a machine with an older Office that will not work. So if you have different versions at the client side you are normally forced to develop with the oldest available version or recommend the client to install the same version on all clients (which should normally be the case...).
Moreover, you should no longer use the Access security system because it was officially removed in A2007, although it can be used here for compatibility reasons. In A2010 it is no longer available. You should consider to use a SQL Server as backend to which you can migrate easily and if you want you can install the Express version which doesn't cost anything (not more than a server which runs it). The security model of SQL Server is much better than Access ever was.
I personally use InnoSetup to create installers. This one is free and very comfortable and it produces very small installers.
Cheers,
Christian
ASKER
To LSMConsulting: I removed the Common Controls reference. That was left in by mistake, having used one of my old systems for its existing code. I should have thought of removing redundant references. As for Microsoft Office 12.0 Object Library, my usage is the msoFileDialogFilePicker. Access Runtime is the only runtime installed. The Object Library as I understand just gives you coding ability, not requiring the entire suite of that version (12.0). Am I right? Many thanks.
To TheHiTechCoach: I removed the OLE Aut reference. Late Binding will be attempted later. Many thanks. PS what is a "trusted location?"
Fully qualified objects will be implemented. The Common Controls reference has been eliminated. Some client machines will have older Office so that will have to be taken into account. So I guess there's a danger in upgrading my system to Access 2013 to get Microsoft support spanning the next 2 versions? Many thanks.
ToBitsqueezer: I've downloaded InnoSetup. Thanks so much for this suggestion also.
To TheHiTechCoach: I removed the OLE Aut reference. Late Binding will be attempted later. Many thanks. PS what is a "trusted location?"
Fully qualified objects will be implemented. The Common Controls reference has been eliminated. Some client machines will have older Office so that will have to be taken into account. So I guess there's a danger in upgrading my system to Access 2013 to get Microsoft support spanning the next 2 versions? Many thanks.
ToBitsqueezer: I've downloaded InnoSetup. Thanks so much for this suggestion also.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
Are you actually using the reference for "OLE Aut". If not, remove it.
Sounds like a missing reference issue. I would highly recommend convert as much as you can to using Late Binding. This will allow you to use whatever version oif the other Office apps that are installed.
See: Late Binding in Microsoft Access
You may also be having a version issue with "Microsoft Windows Common Controls 6.0 (SP6)". Curious, what are you using this to do?
What is the Windows OS versions, including 32 or 64 bit, you are using to compile the .accde?
FWIW: I compile my accde or mde on Windows XP. This avoids Windows version reference issues.