Can you enable macros for Access through the registry? If so, what is the path?
Take a look at the following registry hive:
software\policies\microsoft\office\16.0\outlook\security
where 16.0 should correspond to the host application version.
See Security setting for macros for more information about possible values.
Related
It's been our experience that non C2R MS Access DBMS installations seem to break after any MS Office SxS install or update occurs. Have seen this with 2007, 2010, and 2016. We didn't try 2013. To get the application working again, we need to repair the MS Access installation that we are using.
Presently, we're only using the 32 bit provider. We have been using the DAO Database object to perform database restructuring.
Thinking of migrating to the Click2Run MS Access 2019, I tried to use this instead but found that DBEngine is not made available outside the C2R "bubble". I don't see a way I can instantiate or ask for an existing Database instance. This is a problem because then the database restructuring won't work.
When using Click2Run/SxS MS Access DBMS via ADO, how can I access Database object to be able to use DAO to restructure the database?
You simply have to install the ACE engine from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
However, if you want to know how this really works?
Well, it rather important to distinguish between Access. Access is a developers tool like vb.net, or FoxPro or whatever. It allows you to write code, and consume data from a database of your choosing.
So Access is not the database nor is access a database. I mean, how does one create forms and a user interface with SQL server? You can't!!!
So a few things:
Up to Access 2010:
If you install Access system, then it ALSO installs a version of the database engine (used to be called JET, but now it called ACE).
So, installing access the development system, or even the access runtime?
It would install and register and expose a copy of the ACE database engine.
You could thus use the ACE database engine in 3rd party tools. (such as VB6, or say vb.net/ c# .net).
Now, for Access 2013, and 2016? Well by default since most office installs are C2R, they also changed that when installing 2013 and 2016 they DO NOT expose a external copy of the ACE data engine.
For 2019, due to some confusing by the general developer community? Well they now re-introduced that installing Access (full edition, or runtime) is NOW back to the way it was in the past.
That past was installing Access also installed a EXPOSED copy of ACE.
So, for 2019, this long time setup has returned (even for C2R).
Just as the whole community was getting used to this new setup, we now back to what it was like in the past!!
Having a self contained and NON exposed copy of ACE has some rather nice advantages. One big advantage is that you can now install a different version of ACE - including the mixing of x32 and x64 ones.
So, installing Access as a develope9rs tool should not have for all these years also exposed the ACE database engine. This is especially the case since many now use Access with SQL server, or even SharePoint. So, now Access is not the database. Even a bound form to a sql table with 1 million rows of data? Access is smart, and if you open the form with a standard built in "where" clause, Access will ONLY pull the one record. I note this issue, since once again, Access is NOT a database. It is a system to build applications with, and has things like code, reports, and that of a user interface to build applications with.
Once you choose Access, you THEN choose the database, and it does not have to be ACE
Ok, now all above is clear.
To use the ACE database engine?
Simply install it. Use this link:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
As noted, for 2019, the return of ACE being installed + exposed when you install Access is retuning. However, between:
So, we have for access 2010, 4 versions:
Access x32 - full edition
Access x32 - runtime edition
Access x64 - full edition
Access x64 - runtime edition.
For Access 2013, we have 8 versions.
Access x32 - full edition - MSI
Access x32 - runtime edition - MSI
Access x64 - full edition - MSII
Access x64 - runtime edition. NSI
Access x32 - full edition - CTR
Access x32 - runtime edition - CTR
Access x64 - full edition - CTR
Access x64 - runtime edition. CTR
So, what will and will not work. And what version to install was becoming a HUGE matrix of possibilities.
Bottom line:
If you need ACE for external 3rd party use? Then install the ACE engine, and NOT bother to install access or assume Access will install a exposed copy of ACE).
I could write on for 20 more pages about the options, and what versions you can, or cannot mix. But with 8 versions that narrative will be rather large. Anyway for the time being, you can't assume that installed Access will install a exposed copy of ACE.
So, for the time being, you have to install ACE.
Over time, we will be back to how this worked in the past, and this is especially the case since MSI versions of office are becoming VERY difficult to fine, or obtain. You quite much forced to choose C2R, and MSI installs from physical media (or even a download) is a thing of the past.
We have a 2007 Access database application that we would like to deploy to a large number of users at various sites with different versions of Access (some without an install of Access and just instructions to install the Access 2007 Run Time) for a data collection effort. We were planning on deploying it as an ACCDE file with compiled VBA code - we noted that users with 2007, 2010 and 2013 could open this file. However, during testing, we discovered that at least one of our user's computers had 2010 installed but, the 64-bit version of Access/Office and we received the following error message upon trying to open it:
This database was created with the 32-bit version of Microsoft Access.
Please open it with the 32-bit version of Microsoft Access.
We are now looking for some alternative options to account for this unforeseen compatibility issue. The application was developed on a 32-bit version of Access 2007.
If we were to deploy the ACCDB file, instead of the compiled ACCDE version, would 64-bit version of Access still be able to run it?
For all years 2007-2013?
Also, would users with just the 2007 Access Run Time still be able to open just he ACDDB file?
If we were to deploy the ACCDB file, instead of the compiled ACCDE version, would 64-bit version of Access still be able to run it?
Generally speaking, yes. Provided that
there are no 32-bit third-party ActiveX controls being used, and
calls to the Win32 API (if any) are pointer-safe
then the 64-bit versions of Access will be able to recompile the VBA code automatically when the .accdb file is opened. (They can't do that with the .accde file because the .accde file does not contain the VBA source.)
Also, would users with just the 2007 Access Run Time still be able to open just he ACDDB file?
I would expect so, particularly since Access 2007 was still 32-bit only (as I recall). Of course, the best way to know for sure would be to try it and see.
Macros and VB macros are very limited in Access.
I've good C#/.NET skills and created an app with System.Runtime.InteropServices.Marshal.GetObject (captures some process) to use with Microsoft.Office.Interop (makes some Office stuff).
It's works like a charm with .accdb files (MS ACCESS 2010), but when i want to automate mdb base with security...
For example, i can't get Access process with opened DB:
C:\Program Files (x86)\Microsoft Office\Office14\MSACCESS.EXE \server\database.mdb /WRKGRP "\server\security.mdw"
New process just starts.
I decided to create an Office Add-In for Access 2010... but when user opens shortcut above - it's just not loading.
Is there any possible solution to open/get/capture Access process with opened mdb database?
upd1: i'll try to play with msaccess cmd startup arguments
Got it!
http://support.microsoft.com/kb/317114/
Look at GetShellApp method - you can pass any arguments and connect to encrypted\user-based-access DB
I have a windows form application that uses microsoft access for the database on the backend.
When I run that application I get an error that says access is not installed on the computer. I thought that if I included the reference that it will be included with what I release so the user would not have to have access installed.
How do I include the Access Runtime to be distributed/installed when my application is installed?
Have you tried downloading the latest MDAC release, if your application is only connecting to an Access DataStore, the local machine requires the drivers to make the connection.
I am going to use the MS Access Runtime or direct the user to download a trial version of MS Office.
MS Access Runtime 2007
I tried it out and the app works. If their is a better option I would like to know.
Microsoft provides instructions for how to deploy an Access Runtime Application. Is there something about those that doesn't fit your scenario?
Anyone knows if it is possible to install Access 2003 standalone without the rest of the Office 2003? I seem not to locate my installation disks to test this out, but thought someone might have an answer...
I believe so, when you install Office and choose custom install, you can deselect everything except Access.
You can do a custom install and then deselect everything.
You will basically get all the MS Office run-time and shared components with only the Access application available to run.
Note: I don't use the access run-time any more, but do use it regularly for the Excel and/or Word applications.