I have programs (created using VB.NET 2008) interacting with .mdb files (created in access 2003). use Oledb 4.0.
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=MyPath;
Jet OLEDB:Database Password=MyDbPassword;
Works fine on all my computers: W8 Pro, XP, 2003, Vista, Windows 7, ....(32 and 64 bits).
But with the upcoming end of support and updates for office 2003, should it also be necessary to migrate our databases .mdb (created with access 2003) to a higher version? affects or this is not necessary if we do not use Office 2003?
No you don't need to upgrade your app to a newer version of Jet (and no, there is no new version of Jet), you could still use that bits until they are supported by the Net Framework OleDb classes and the libraries present on the target machine.
The version of Office installed by your user has nothing to do with that.
Of course this library is outdated. The new bits for opening a Microsoft Access database in the new format (ACCDB) are called Microsoft.ACE.OleDb.12.0 and you can find the connection strings on this site
These new libraries allows to write application for 64bit but I can't really recommend to switch to a 64 app unless you have compelling reason to do that. For more info see this question
Updates for Office are only for Office. I doubt that there's been an update to Jet 4.0 for some time.
Related
before I use MS Access 2010 32 bit link to Visual FoxPro through ODBC driver. after I upgrade to MS Access 2016 64 bit. the ODBC driver does not show Visual FoxPro databases. and Access cannot connect to VFP. anyone can advise?
There never was nor is a x64 bit version of FoxPro. As a result, if you want to consume VFP files? Then your .net project has to remain x32 bits.
And same goes for using the VFP odbc driver. They are x32 bits only, and thus your .net software, or in this case ms-access software MUST remain as the x32 bit version.
Foxpro is x32 bit technology only - and thus any software that interacts or is to consume VFP data also must remain as x32 bits.
You can't use the x64 bit version of Access - it will not work with x32 bit software.
I have 32-bit Office installed together with 32-bit AccessDatabaseEngine on a laptop with 64-bit Windows 10.
With 32-bit Office goes 32-bit ACE although Office does not use ACE (but VBA can do) and (Microsoft disallows 32- 64-bit ACE 12.0 to coexist on the same computer).
Using an identical connection string and sql statement, I am able to use ADODB successfully but a C# COM server is giving me this error:
The 'Provider=Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine.
I am also able to Import Data from xlsx sources in SQL Server Management Studio.
It appears that the C# Com server is looking for the 64-bit version. I have specified x86 as the target platform for the C# project.
Any hints on how to overcome the error with the C# COM server? Why does C# default to using 64-bit ACE 12.0 (ADODB & SSMS do not)? Is there a way of coercing the use of 32-bit ACE in the C# project - I've already specified x86 as the target platform?
Thanks.
I have a VB.NET application that uses a .accdb access file (2010 version) as a backend. The application only reads from this DB file, no writing ever. The application and database file need to be deployed together on the user's PC.
I understand that users will need either:
1) Full version of Access installed already or
2) The runtime installed
in order for the application to run.
That's fine and dandy but my problem is that the AccessRuntime.exe is HUGE (175 MB) and I would rather not deploy it with my app if I don't have to. Is there a way to just deploy the needed Runtime DLLs/files with my VB app and DB file? If so, what/where are these files located?
If your .NET application will just be reading the Access database file via System.Data.OleDb or System.Data.Odbc then you don't need the Microsoft Access Runtime. You just need to have an Access database engine installed, either
the older "Jet" database engine, if you only need to access .mdb files from 32-bit applications, or
the newer "ACE" database engine if you need to access .accdb files (or .mdb files from a 64-bit application).
Since your database apparently does not need any specific Access 2010 features you can just convert your .accdb file to an .mdb file and use the "Jet" database engine that is already installed on all Windows machines. However, Jet is only available to 32-bit applications so you need to go into your VB.NET project and target it to the x86 platform so it will always run as a 32-bit application (even on 64-bit machines).
Edit
If you want to manipulate an .accdb database file then you need to ensure that the Access Database Engine ("ACE") is installed on each machine. The installer is available for download here:
Microsoft Access Database Engine 2010 Redistributable
Notes:
There are both 32- and 64-bit versions of the ACE database engine. The installed version must match the "bitness" of your application (32-bit or 64-bit). This can be tricky, because Microsoft has designed the ACE installers so that you can have either the 32-bit or the 64-bit version installed. (There is a workaround that can force-install both, but it is not recommended because it can break Microsoft Office.)
Further to point #1, so even if you target your .NET app to the x86 platform and require the 32-bit version of ACE you can still have difficulties dealing with target machines that already have the 64-bit version of Office installed. They cannot install the 32-bit version of ACE because the 64-bit version is already installed. So, to use your app they would have to uninstall the 64-bit version of Office and install the 32-bit version.
As far as I know there is no practical way to include the ACE installer in the setup program for your application. Your users would need to download and install the appropriate version (from the link above) for themselves.
we have a mixed environment. Some workstations have Microsoft Office 2010 installed while others have Microsoft Office 2007 installed. A lot of our in-house developed applications are referring to the Outlook 12.0 object library and the Excel 12.0 object library. In Office 2010 these are referring to the 14.0 object libraries. Is there a way when users launch an Access application that it checks which version of Office they have installed and when it detects either Office 2007 or Office 2010 so that it can programatically set the correct references to the Object Libraries?? Many thanks for any help and/or suggestions.
Set the references to use the earliest version of the reference and Ms Access will automatically upgrade the reference for later versions of Access if needed.
For example, if none of your workstations use anything less than Access 2007, you should set the reference to Excel 12.0. Any workstation using Access 2010 or 2013 will update the reference automatically for their local copy
I've had similar conflict issues between office 2010,2013 and 2016.
I think the whole point of initiating this thread is that "should" <> "does"...
Meaning that programing to the earlier version does not "always" work when the user PC is not running the exact same version of MS Office that was used during development.
I think maybe need to somehow add both object references to the compiled version and then the app can pick.
In other words, I think the development PC needs to be running both versions of Outlook.
You could also alternatively develop the app on a PC running the earlier version and then save off a copy to be compiled in a newer version of office on a different PC. You'd be basically generating versions specifically for each version of Office.
I am struggling to apply an existing 32bit COM addin to 64bit Microsoft Word 2010.
To make the addin visible to Word, I have used the dllsurrogate-method, as it described here.
The problem is that now addin caused some strange exception when tries to add its toolbar and menu to office's. I cannot figure out, what it is, it seems, that the command bar reference became not valid in unpredicable moments.
Can anyone explain this?
Note, that everething is fine when I use the same addin under 32bit Microsoft Word 2010 and more old versions of Ms Office.
32-bit add-ins are not supported on 64-bit. Microsoft recommends to use the 32-bit version of Office unless you run into the memory limitations of a 32-bit process which is only likely to happen if you need to deal with extremely large spreadsheets:
The recommendations for which edition of Office 2010 to install are as follows:
If users in your organization depend on existing extensions to Office, such as ActiveX controls, third-party add-ins, in-house solutions built on previous versions of Office, or 32-bit versions of programs that interface directly with Office, we recommend that you install 32-bit Office 2010 (the default installation) on computers that are running both 32-bit and 64-bit supported Windows operating systems.
If some users in your organization are Excel expert users who work with Excel spreadsheets that are larger than 2 gigabytes (GB), they can install the 64-bit edition of Office 2010. In addition, if you have in-house solution developers, we recommend that those developers have access to the 64-bit edition of Office 2010 so that they can test and update your in-house solutions on the 64-bit edition of Office 2010.
If you need to go with the 64-bit version because of the memory limitations you have the following options:
If you have the source code, you can generate a 64-bit version yourself,
You can contact the vendor for an updated version,
You can search for an alternative solution.