I currently have an existing ASP classic app connecting just fine with this code:
Set server = Server.CreateObject("ADODB.Recordset")
server.ActiveConnection = "dsn=[name in ODBC Data Sources];"
I am now trying to write an ASP.NET Webforms app to connect to the same database.
When I try this in .NET:
OleDbConnection connection = new OleDbConnection(@"dsn=[name in ODBC Data Sources];");
I get:
An OLE DB Provider was not specified in the ConnectionString. An example would be, ‘Provider=SQLOLEDB;’.
And with this code:
OleDbConnection connection = new OleDbConnection(@"Provider=Microsoft.ACE.OLEDB.12.0;dsn=[name in ODBC Data Sources];");
I get:
Could not find installable ISAM.
and with:
OleDbConnection connection = new OleDbConnection(@"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=[full path to mdb];Persist Security Info=False;");
I get:
The Microsoft Access database engine cannot open or write to the file ‘[full path to mdb]’. It is already opened exclusively by another user, or you need permission to view and write its data.
I have tried installing both 32 and 64 bit versions of Microsoft Access Database Engine 2016 along side 2010 which the asp classic requires. I have also tried targeting x86 and x64. I have also tried giving permissions to the database file for user NETWORK SERVICE. None of the other SO seem to help.
2
Answers
The solution ended up being adding read write modify permission for user IIS_IUSRS. It was a shot in the dark. Someone who knows why please add a better answer.
Don’t use the win32 ADO object.
Use the .net provider.
You can use either oleDB, or use ODBC. I actually can make the case that ODBC is a better choice, since then your code (in most cases) will work if you ever migrate the data to SQL Server.
However, standard fare is to use oleDB provider when working with Access.
The next issue?
Access data engine is not .net code (the term is un-managed code). As a result, you have to FORCE your web project to match the version of Access data engine.
That means if you have Access x32 installed, then you MUST force your web project to run as x32. And of course, you can install + use the x64 bit version of Access data engine, and then run your project as x64 bits.
So, you can NOT use "any cpu" for your project.
You also don’t mention if you are using vs2022. in the past this was NOT a issue, but NOW it MOST certainly is a issue. The reason of course is that vs2022 is the FIRST version of VS that is x64 bits (yup – all these years, VS has been a x32 bit product).
So, let’s go though setting up a connection in vs2022.
And we going to assume access x32 bits here.
So, in our project, we thus set any cpu to x32 bits:
This setting:
If you don’t see/have a "x86" (x32 bits) setting, then click on configuration manager in above and create one.
Next up, for this to work, we ALSO must force the web server to run (allow) x32 bits, so this setting:
Ok, with above setup to use x32 Access, then we now can/should/will/good idea to build a connection string.
So,
project->properties->settings
In above, I typed in AccessTEST. And then you hit the "[…]" in above, and the connection’s wizard will be launched for you.
As noted, you can choose oleDB, or ODBC.
Let’s go with oleDB.
So, select Access database:
the default should be the .net oleDB provider.
then:
You can click browse – browse to the access file.
Do NOT skip the test/check/look at/be sure advanced tab, since that lets you select the JET data engine, or the ACE data engine.
So DO click on the advanced button. That is this button:
The ACE data engine is required if you using a accDB file. For a mdb file, you can use ACE or JET. BUT JET is only x32 bits. so, if you plan to use x64 bit project, then you MUST always choose ACE.
That is this selection after hitting advanced.
Now, it SHOULD default to ACE, but do NOT skip that check/look at/setting it/being 100% sure!
Now back to the main panel. You CAN ONLY use test connection if you are running a version of vs BEFORE vs2022. That is this button:
However, if you are running vs2022, test connection WILL ALWAYS fail since vs is now x64 bits.
(well, it will work if you using + installed ACE or Access x64 bits.)
However, when you run the project, the connection will work just fine.
So do keep this issue in mind.
again:
Test conneciton WILL NOT work in vs2022 UNLESS you are using, chooseing and adopting a x64 bit version of Access/office/ACE.
So, test connection can work if you using full x64 bits, and forced the whole project (and web setting) above to x64 bits. But, for this example, we are assuming x32 bit Access.
OK, so now let’s try some test code.
Let’s drop in a grid view, say like this:
Now, unfortunately, you can’t use the wizard builders (unless you installed access x64, or are using a version of vs BEFORE verison 2022).
so, say this markup:
Nothing special.
And code behind to now use that conneciton?
This:
And now we see this when we hit f5 to run: