Nothing about your application is modified by "packaging" it. This means that if the Access application you distribute with the "run-time version" of Access isn't secured, and the end-user installs a full-version of Access on the machine, they will be able to modify your data and application objects. If they don't, the licensing key gets updated to indicate that the user will be running MSACCESS.EXE in run-time mode (certain windows, toolbars, menu items and keys are hidden or disabled). Then the Windows Registry licensing key gets checked to see if the user has a copy of Access installed. However, when you distribute the MSACCESS.EXE with a copy of your application (via the Package and Deployment Wizard), some of the features of the Access engine a simply disabled on the end-user's machine.ĭuring deployment, a copy of MSACCESS.EXE gets placed on the end-user's machine.
Being able to distribute the "Access Runtime" simply means that you have a license to distirbute the the MSACCESS.EXE file, which is the exact same engine you use to build your Access application using your full version of Access. mde file format) along with a copy of the Access Runtime version. You can however, "package" an Access application (usually in. your standard executable file that a machine running 32-bit Windows would be able to load and do something with. There is no way to "compile" or "build" (via a VBA or Access "compiler") an Access project into a standard Win32 PE (portable executable) file, i.e. Quote:I have been told by IT there is a way to "compile" frontends, and distribute to some of the systems, as long as we have some machines running Access.
0 kommentar(er)
