I'm currently using access database engine 2010 (AccessRuntime 2013) to open and query various database files, .xls, .xlsx, .accessdb, .xml, .txt/csv/tab, .mdb, .dbf, etc...
But now I need to build a x64 application to do the same. However this creates a problem, on x64 PC's that still run Ms Office x86 or have other applications that use the x86 Access Database engine 2010.
The Access x64 runtime wont install next to the x86 version (you can force Access Database engine 2010 with /passive but this damages the x86 version and stops some applications to work at all (including old versions of my own software).
I've read a tone of topics about this issue, but never a solution.
I'm searching for an alternative to the Microsoft access database engine/runtime that allowes me to query various database files in C# or C++
Does anyone have any suggestions how to achieve this?
Related
As part of a C# program that i trying to fix I run it on my machine and i got this error:
I figured out that the problem is with my Microsoft Access Database Engine and i install the 64 bit version but i got this message :
and i tried to install the 32 bit version and i got this message :
someone saw something like that and can help me please?
Ok, a few things:
First, you have to decide or determine what bit size your going to run your .net application as.
If you chose "any" cpu, or choose x86 then of course your .net application will run as x32. The reason why "any cpu" ALSO runs as x32 bits is because Visual Studio (VS) is a x32 bit application. So "any" means .net will take on the bit size of the host process.
The simple issue is you need/want/better specify the .net project bit size and force this issue. If you don't then you can wind up wasting a whole afternoon. KEEP VERY much in mind that if you decide and are using x64 bits for your .net application? Well, you CAN STILL use the connection string wizards and builders in VS, but when you go to TEST connection, for a x64 bit version the test connection dialogs in VS will fail. This is because VS is a x32 bit application. So, even with x64 bit ACE/AccessDatabase, you find the test connection wll fail. However, if your application is set to x64, then running it will work. So, keep this quirk in mind. So, while VS is x32 bits, when you run/debug the application it will respect your project bit settings, but the connection builders will fail on test (so you can use the connection builders - say in the settings panel from VS, but the test connection button will fail).
So, don't use "any cpu" for your project settings. Use x86, or x64 (ie: the bit size you want and plan to use).
Next up:
Normally if you have office (and access) installed, in the past, then this would expose and allow use of the ACE database engine. However, for office 2013 and onwards, installing office, Access, or Access runtime DOES NOT expose the ACE database engine anymore. Because of large amounts of confusing on this issue, for Access 2019, (full or runtime), they have reversed this policy. (so, now once again ACE will be exposed with a Access install).
And prior to 2013, installing Access full or runtime will also work and expose the ACE database engine.
Note that it is recommended that you use the SAME connection string for all versions of the ACE database engine. (from 2007, all the way to 2019). That correct connection string is thus this:
That means for ACE 2007, 2010, 2013, 2016, 2019, we are to use this:
If using oleDB provider then:
Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\test2\test44.accdb
If using ODBC provider then:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};
dbq=C:\Test2\test44.accdb;defaultdir=C:\Test2;
Installing the ACE data engine in place of the larger and heaver Access (or access runtime) install.
Now, assuming you don't have Access installed. And assuming that you dealig with 2013, 2016, then you quite much need to install the ACE data engine.
You want to download the ace engine from here:
https://www.microsoft.com/en-us/download/details.aspx?id=54920
Make sure you download and attempt to install the correct bit size version.
Getting around the dialog boxes that complain about office x32 or x64 already having been installed. It turns out that so many bits and parts of office are shared between all programs, that if you install say Excel, x32, then you cannot install ANY OTHER office program from word to power-point or Access as x64. You can install DIFFERNT versions of office, but NEVER mix and match bit size for a GIVEN version of office. This is due to the large amounts of .dll's and shared code between office programs.
HOWEVER, you CAN force the ACE engine to install , and install regardless of the bit size.
Download the ACE engine install (your desired bit size). But now launch the installer from the command line. Add the /quiet switch to the install. This will cause the installer to by-pass the nagging and complains about the bit size.
So, from command prompt, go:
C:\runtimetest>AccessDatabaseEngine.exe /quiet
or for x64, I think its:
C:\runtimetest>AccessDatabaseEngine_64.exe /quiet
(going form memory - but just use the /quiet swtich - it should allow you to proceed with the install.
Last but not least:
You can download my sample utility here:
https://1drv.ms/u/s!Avrwal_LV4qxhpdBSWWSP5Ivv38AZw?e=dTVQis
It is a small tiny .net exe file (no install). It has a x32 bit version, and a x64 bit version. You can run/try/test either version to see which bit size of access works, or is installed.
It shows this:
If the above utility don't work (x32 or x64 version), then you don't have a valid working ACE database engine installed.
I have an application written in C# (VS 2013) which is connecting to a database using MySQL. Is it possible to run this program on another computer without installing MySQL, which has VS 2010. i wish to run the application with .exe file, if that is possible?
Furthermore, the application is about collecting information about Academic/Recruitment Tests through "forms" so the information is updated in the database also.
Thank-you
I don't know if I got you right, but you can run the compiled EXE file on every system that offers the .NET version specified in your project settings.
I have finished designing my C# application which stores employees data in an Access database. The program works perfectly when I install Microsoft Office 2007 on my machine, but causes an error if I uninstall Office 2007. Now, I wonder if there is a method which enables my program to connect to the Access database without installing the whole Microsoft office 2007.
using System.Data.OleDb;
If your connection string uses the Microsoft.ACE.OleDb.12.0 provider then you need the Microsoft Access Database Engine installed on the client.
At the link provided you could find the installation of the two versions of this provider.
One for 32bit and one for 64bit.
The right one to use depends by the Target CPU defined in your app and by the operating system bitness. Of course on a 32bit OS you cannot install a 64bit provider while the reverse is possible.
If your app is compiled for x86 as Target CPU then you need the 32bit version and you could install your app also on 64bit systems. If your app is compiled for x64 Target CPU then you need the 64bit version and you could run only on 64bit systems. If your app is compiled for Any CPU then you should decide at install time which version of ACE.OleDb.12.0 to install depending on the bitness of the operating system.
If this is not enough to give you headache then things start to look very bad if there is an Office already installed on the client machine.
Office installs automatically the provider compatible with its version (32 or 64 bit) and you cannot install a different version of these libraries side by side with the other one.
So what are your best options?
Write your app for x86 Target CPU and provide a dedicated setup for
systems where Office 64 bit is installed or ask your customer to change Office version. (I'm kidding)
Write your app for AnyCPU Target, check at install time the OS bitness and choose the appropriate version of the engine. On 64bit systems hope that your customer has not
installed a 32bit version of Office.
Use the Access 2003 format (mdb) and compile for x86 Target CPU. This
approach requires the Microsoft.Jet.OleDb.4.0 provider that should
be already available on any target client. It doesn't require to install
anything and it should work flawlessy on any system.
Switch to SQLite or Sql Server Compact Edition or Sql Server
LocalDB. These options requires a complete retesting of the
application, database schema migration and probably code changes. Still, dedicated
libraries, are needed to distribute
Personally for small, single user applications, with limited amount of data (less than 1gb) and with integration with other Office applications I use the Access 2003 MDB solution.
I have spent several days trying to solve this problem with no luck and my requirements are really simple - I want to make an application with database which will work on most PCs (without DB server installed) and I want to use LINQ. For the compatibility reasons I want to use .NET framework 3.5 (every Windows 7 machine has it).
I have tried 2 ways: SQL Server CE and SQLite.
SQL Server CE
Although Visual Studio does not support LINQ for Compact Version of SQL server, I have found simple workaround - generating .dbml file using metal.exe tool from Visual Studio and then dragging it into project. My application works fine on my machine, but when I copy it somewhere else, it crashes. I have copied all dlls from C:\Program Files (x86)\Microsoft SQL Server Compact Edition\3.5 and tried 4.0 too. I think problem is that my app is not looking for dlls (references) inside its directory. I managed to get it work using DataSets (without LINQ), where I manually add reference to SQLServerCE and check CopyLocal to true. BUT when I use LINQ, there is no reference to SQLServerCE in project references and it is working. I don't know how to change it. Or is there a problem somewhere else?
SQLite
After long messing with SQL Server CE, I have tried SQLite. I am very disappointed how poor is SQLite support in .NET. I had to download older version of ADO.NET provider (newer versions does not add SQLite Database into my Visual Studio 2010 - I don't understand why but I googled that it is normal and I have to install old version and then replace it with newer). Then I downloaded dblinq (I have discovered that this project is dead later) and after some messing with dbmetal and dlls I get rid of errors in Visual Studio and compiled my application. But I can't run it, it always crashes on error 40 - like there was no SQLite server. Of course I have copied all dlls. I can't run it even on my development machine.
I am very surprised that it is nearly impossible to create simple database application in C# .NET which will not bother client with servers etc.
Please is there anyone who made SQL CE work with LINQ and mainly who made his app distributable?
I would suggest you try using the nuget Entity Framework for SQL CE package. It will download all the required assemblies to make it work.
http://nuget.org/packages/EntityFramework.SqlServerCompact/
Information
I'm using VS 2012 to develop a desktop WPF application (should run on win 7 and 8 later it will get a win 8 app),
with an embedded Firebird server,
and communicate with entity framework.
I'm using win 7/8 for development both with VS2012.
Problem
The application should work with embedded firebird at customer PC (no installation of FB).
I did Install the DDEX Provider for Visual Studio(3.0.0.0), as far it worked. I could add a new firebird connection (but getting error fbembed.dll not found). so i cant create the edmx file.
Do i need to install the firebird server(Superclassic/Classic or Superserver) or is it enough to just use Embedded server on my developer PC? if embedded is enough do i need to register the firebird client on gac?
as far i didn't found any useful information how to install and use it, and how to deploy it. do you guys have some good information links?
For embedded server you just have to deploy the Firebird files along with your application and put the dll file somewhere accessible for it, for example, in the same folder.
The minimum files you have to deploy to get Firebird working is:
FbEmbed.dll
icudt30.dll
icuin30.dll
icuuc30.dll
firebird.msg
firebird.conf
This information, along with more usage instructions, is available in the file doc\README_embedded.txt.
USAGE
Just copy fbembed.dll, icudt30.dll, icuin30.dll and
icuuc30.dll into the directory with your application.
Then rename fbembed.dll to either fbclient.dll or
gds32.dll depending on your database connectivity software.
Then start your application and it will use the embedded
server as a client library and will be able to access
local datasases. You should also copy firebird.msg and
firebird.conf (if necessary) to the same directory.
If external libraries are required for your application,
then you should have them separately. Most probably, it
will be INTL support (fbintl.dll and fbintl.conf) or UDF
libraries. To be able to use them, you should place them
into the directory tree which emulates the Firebird server
one, i.e. has subdirectories like /intl or /udf: