cant find the Microsoft.ACE.OLEDB.16, neither the Microsoft.ACE.OLEDB.12

I dont get the Microsoft.ACE.OLEDB.16 driver.
Even Office 2016(x32 version) is istalled on Win7 and a Win10 system. Both of them are x64 systems.
But Win10 does not have it, neither Win7.
I changed than the net project to ‘AnyCpu’, but no matter if target is 64 or 32, cant find the driver.
Considering this threads,
https://stackoverflow.com/questions/...-on-the-system

at least I excpect to get the Microsoft.ACE.OLEDB.12 driver.
I have no Idea whats left here.
If Office is a 64 version, than I would have expect this situation, but not on with a x32.

Code:

---

public static bool GetMsACEDriver()
        {
            OleDbEnumerator enumerator = new OleDbEnumerator();
            DataTable table = enumerator.GetElements();
            bool bNameFound = false;
            bool bCLSIDFound = false;

            foreach (DataRow row in table.Rows)
            {
                foreach (DataColumn col in table.Columns)
                {                 
                    if ((col.ColumnName.Contains("SOURCES_NAME")) && (row[col].ToString().Contains("Microsoft.ACE.OLEDB.16 ")))
                        bNameFound = true;                                               
                }
            }
            if (bNameFound)
            {             
                return true;
            }
            else
            {
                return false;
            }
        }

---

What are you really trying to do? Build a list of drivers or some other work like connect to a database?

Its a WinForm application, which shall connect access databases, but first it has to watch, which drivers are available.
(should have mention that in the first place)
For now, i dont see any other option to force the app to connect those databases and if it throws an error, return false.

Not an expert with access dbs, but do you really need to know the driver version? From what I see, the wizard requires it, but does OleDbConnection require the access version in the connection string?

https://msdn.microsoft.com/en-us/lib...onnection.aspx

not the access version, but which driver is installed. For now it seems so, up to access 2010 (db format has changed from mdb to .accdb) it doesnt matter , if the system has Oledb.12, or OLEDB.15, or 16. connection will be possible no matter if the database were created with office 2010... till 2016. But if it is an mdb format, windows has to have the "jet.oledb.4".

But I'm not really sure, just some how it seems for now.
ANd then there is something else, couldnt find the thread again, it says, if Office is a x64 version, but your system runs as x32, your winform net project cant load the driver.
As longer as I go, as more leads to a never ending story.

I see that you need the Ole object name (driver) for the OleDbConnection connection string. What a pain. Do you have Office 64-bit installed or 32-bit?

Yes and no. The WinformApp has no idea which enviroment it has to expect. The user installed it and then it has to look whats possible.

Write some test programs that use the GetMsACEDriver code and display to the console. Compile for 32-bit and then compile for 64-bit.

Post the list of differences here and let's see if we can figure out an approach.

Unvortunatly, i dont have a x64 office version, couldnt get it.
Here it is, 4 lists, first Win7 then Win10. Win10 has only Office 2016.
Both of them (Win7 and Win10 havent found an acces driver, if it is compiled to AnyCPU)
thast the code, I've used, same as above, but might be easier to red:

Code:

---

static void Main(string[] args)
        {
            OleDbEnumerator enumerator = new OleDbEnumerator();
            DataTable table = enumerator.GetElements();         

            foreach (DataRow row in table.Rows)
            {
                foreach (DataColumn col in table.Columns)
                { 
                    if (col.ColumnName.Contains("SOURCES_NAME"))
                    {
                    Console.WriteLine("SOURCES_NAME =" + " " + row[col].ToString());
                    }                 
                }
            }         
              Console.ReadLine();
        }

---

Results of: compiled x86, Win7 x64, with Office 2003, Office 2010, Office 2016(all of them x32 versions)
VS2010 Console-Project, Net Framework 4.0,
SOURCES_NAME = MediaCatalogDB OLE DB Provider
SOURCES_NAME = SQLOLEDB
SOURCES_NAME = MSOLAP
SOURCES_NAME = MSOLAP
SOURCES_NAME = MediaCatalogMergedDB OLE DB Provider
SOURCES_NAME = MSDMine
SOURCES_NAME = MSDataShape
SOURCES_NAME = Microsoft.ACE.OLEDB.12.0
SOURCES_NAME = ADsDSOObject
SOURCES_NAME = MediaCatalogWebDB OLE DB Provider
SOURCES_NAME = MSDMine Enumerator
SOURCES_NAME = SQLNCLI10
SOURCES_NAME = SQLNCLI10 Enumerator
SOURCES_NAME = Windows Search Data Source
SOURCES_NAME = MSOLAP
SOURCES_NAME = MSOLAP
SOURCES_NAME = MSDASQL
SOURCES_NAME = MSDASQL Enumerator
SOURCES_NAME = Microsoft.Jet.OLEDB.4.0
SOURCES_NAME = SQLOLEDB Enumerator
SOURCES_NAME = MSDAOSP
SOURCES_NAME = MSDAORA
SOURCES_NAME = MSIDXS

Results of: compiled AnyCPU, Win7 x64, with Office 2003, Office 2010, Office 2016(all of them x32 versions)
VS2010 Console-Project, Net Framework 4.0,
SOURCES_NAME = SQLOLEDB
SOURCES_NAME = MSDataShape
SOURCES_NAME = ADsDSOObject
SOURCES_NAME = SQLNCLI10
SOURCES_NAME = SQLNCLI10 Enumerator
SOURCES_NAME = Windows Search Data Source
SOURCES_NAME = MSDASQL
SOURCES_NAME = MSDASQL Enumerator
SOURCES_NAME = SQLOLEDB Enumerator
SOURCES_NAME = MSDAOSP
SOURCES_NAME = MSIDXS

Results of: compiled AnyCPU, Win10 x64, Office 2016(x32 versions)
VS2010 Console-Project, Net Framework 4.0,
SOURCES_NAME = SQLOLEDB
SOURCES_NAME = MSDataShape
SOURCES_NAME = ADsDSOObject
SOURCES_NAME = Windows Search Data Source
SOURCES_NAME = MSDASQL
SOURCES_NAME = MSDASQL Enumerator
SOURCES_NAME = SQLOLEDB Enumerator
SOURCES_NAME = MSDAOSP

Results of: compiled x86, Win10 x64, Office 2016(x32 versions)
VS2010 Console-Project, Net Framework 4.0,
SOURCES_NAME = SQLOLEDB
SOURCES_NAME = MSDataShape
SOURCES_NAME = ADsDSOObject
SOURCES_NAME = Windows Search Data Source
SOURCES_NAME = MSDASQL
SOURCES_NAME = MSDASQL Enumerator
SOURCES_NAME = Microsoft.Jet.OLEDB.4.0
SOURCES_NAME = SQLOLEDB Enumerator
SOURCES_NAME = MSDAOSP
SOURCES_NAME = MSDAORA

That's jacked up. :) I can think of an approach to make this work and that is put the detection code into an assembly and mark the assembly to compile as 32bit. Seems like a real hack though.

Instead, how about this...? Include the Access 32 and 64 bit redistributables as part of the setup of your program and install the appropriate version when your program is installed. Then you know a particular driver version will always be available (and you don't have the hassle of searching for it).

Well, have done, this are the conditions I set up.
RedistryEntry1:
Property = RegistryValue1
RegKey = Software\Microsoft\DataAccess
Root = vsdrrHKLM
Value = FullInstallVer

Condition1:
Condition >=”2.7”
Message = “No driver found”

No error occurred packing the setupproject, no error during installation , but finally it doesn’t realized that there is no driver for MDAC 2.7 or higher. I used it on Win7x64 and Win10x64, with a winformproject compiled to “AnyCpu” and Target to x64(Setup properties)

MDAC??? Is that still in use? I was thinking more of the access redistributable. This is a link to the exe. It might be able to be installed in silent mode. If not, find the equivalent msi.

http://www.microsoft.com/en-us/downl....aspx?id=39358

(Had to edit above, but doesnt concern your answer)

This will be a solution(install the runtime), but its larger than just the driver like MDAC or WDAC. And finally I have to recognize whats left on customers machine.
MDAC is less using than WDAC(hope so(MDAC is the one needed till AccessXP after its WDAC)).
The steps above are supposed to be the way, during setup process, to figure out whats available. It can be applyfied to condition2 condition3 and so on, but holds no meaning if it doesnt work.

The "Condition1" has to be like "MDACSEARCH >= "2.7""
I put here the whole thing, did not want to edit again, might make confused.

Two things are left.
could not find an option to set a relative path within "InstallUrl", I dont want to run it with a download path to a microsoft webpage, the user has to make a choise there.
And, even there is an option for a reletive path, if the winform_project is compiled to "AnyCpu" and on windows already installed just a x32 Access version, than "AccessDatabaseEngine_X64" cant be installed. Maybe its possible to install AccessDatabaseEngine_X32, but how prepare the setupproccess to make a choise?

What about changing the whole thing, leaving access away and change to SQLCompact, am I rid of driver creepe things?


RedistryEntry1:
Property = RegistryValue1
RegKey = Software\Microsoft\DataAccess
Root = vsdrrHKLM
Value = FullInstallVer

Condition1:
Condition = MDACSEARCH >=”2.7”
Message = “No driver found”

some to add,
here is an example to check if office x32bit or x64 bit is installed
http://www.codeproject.com/Questions...replusisplusit

It works , but cant see how to get it in the setup process. Its possible of course to set more than one condition, but how to force the setup process to make a decision between the result of a first and second or even the third condition