x64 registrado proveedor office microsoft está equipo visual-studio ms-access ado.net oledb

visual studio - office - El proveedor de Microsoft.ACE.OLEDB.12.0 no está registrado



microsoft.ace.oledb.12.0 download x64 (9)

Tengo una solución de Visual Studio 2008 con dos proyectos (un proyecto de plantilla de Word y una aplicación de consola VB.Net para probar). Ambos proyectos hacen referencia a un proyecto de base de datos que abre una conexión a un archivo de base de datos MS-Access 2007 y tiene referencias a System.Data.OleDb. En el proyecto de base de datos tengo una función que recupera una tabla de datos de la siguiente manera

private class AdminDatabase '' stores the connection string which is set in the New() method dim strAdminConnection as string public sub New() ... adminName = dlgopen.FileName conAdminDB = New OleDbConnection conAdminDB.ConnectionString = "Data Source=''" + adminName + "'';" + _ "Provider=Microsoft.ACE.OLEDB.12.0" '' store the connection string in strAdminConnection strAdminConnection = conAdminDB.ConnectionString.ToString() My.Settings.SetUserOverride("AdminConnectionString", strAdminConnection) ... End Sub '' retrieves data from the database Public Function getDataTable(ByVal sqlStatement As String) As DataTable Dim ds As New DataSet Dim dt As New DataTable Dim da As New OleDbDataAdapter Dim localCon As New OleDbConnection localCon.ConnectionString = strAdminConnection Using localCon Dim command As OleDbCommand = localCon.CreateCommand() command.CommandText = sqlStatement localCon.Open() da.SelectCommand = command da.Fill(dt) getDataTable = dt End Using End Function End Class

Cuando llamo a esta función desde mi proyecto Word 2007 Template todo funciona bien; sin errores. Pero cuando lo ejecuto desde la aplicación de la consola arroja la siguiente excepción

ex = {"El proveedor ''Microsoft.ACE.OLEDB.12.0'' no está registrado en la máquina local."}

Ambos proyectos tienen la misma referencia y la aplicación de consola funcionó cuando la escribí por primera vez (hace un tiempo) pero ahora ha dejado de funcionar. Debo extrañar algo, pero no sé qué. ¿Algunas ideas?


¿Está ejecutando un sistema de 64 bits con la base de datos ejecutando 32 bits pero la consola ejecutando 64 bits? No hay controladores de MS Access que se ejecuten en 64 bits e informarán un error idéntico al que usted informó.


Básicamente, si está en una máquina de 64 bits, IIS 7 no está (por defecto) sirviendo aplicaciones de 32 bits, en las que opera el motor de la base de datos. Entonces, aquí está exactamente lo que haces:

1) asegúrese de que el motor de base de datos de 2007 esté instalado; puede descargarlo en: http://www.microsoft.com/downloads/details.aspx?FamilyID=7554F536-8C28-4598-9B72-EF94E038C891&displaylang=en

2) abra el administrador de IIS7 y abra el área de Grupos de aplicaciones. En la barra lateral derecha, verá una opción que dice "Establecer valores predeterminados del grupo de aplicaciones". Haga clic en él y aparecerá una ventana con las opciones.

3) el segundo campo inactivo, que dice ''Habilitar aplicaciones de 32 bits'' probablemente esté configurado como FALSO por defecto. Simplemente haga clic donde diga ''falso'' para cambiarlo a ''verdadero''.

4) Reinicie su grupo de aplicaciones (puede hacerlo presionando RECYCLE en lugar de STOP y luego START, que también funcionará).

5) hecho, y su mensaje de error desaparecerá.


Estoy teniendo el mismo problema. Intento instalar Office 2010 de 64 bits en Windows 7 de 64 bits y luego instalar 2007 Office System Driver: Componentes de conectividad de datos.

después de eso, visual studio 2008 puede abrir una conexión a un archivo de base de datos MS-Access 2007.


Pensé que iba a sonar porque encontré esta pregunta cuando me enfrenté a un contexto ligeramente diferente del problema y pensé que podría ayudar a otras almas atormentadas en el futuro:

Tenía una aplicación ASP.NET alojada en IIS 7.0 ejecutándose en Windows Server 2008 de 64 bits.

Dado que IIS tiene el control de la bitness del proceso, la solución en mi caso fue establecer la configuración Enable32bitAppOnWin64 en true: http://blogs.msdn.com/vijaysk/archive/2009/03/06/iis-7-tip-2-you-can-now-run-32-bit-and-64-bit-applications-on-the-same-server.aspx

Funciona de forma ligeramente diferente en IIS 6.0 (No se puede establecer Enable32bitAppOnWin64 en el nivel del grupo de aplicaciones) http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/0aafb9a0-1b1c-4a39-ac9a-994adc902485.mspx?mfr=true


Supongo que si está ejecutando un sistema de 64 bits con una base de datos de 32 bits e intenta ejecutar una consola de 64 bits, los siguientes paquetes deben instalarse en la máquina.

  1. Instale Microsoft Access Database Engine 2010 x86 Redistributable, esta instalación está disponible en: http://www.microsoft.com/download/en/details.aspx?id=13255 .
  2. Componentes de conectividad de datos de Office 2007, esta instalación está disponible en: http://www.microsoft.com/download/en/confirmation.aspx?id=23734 .
  3. Microsoft Access Database Engine 2010 x64 redistribuible. Tendrá que descargar el paquete localmente y ejecutarlo con un indicador pasivo. Puede descargar la instalación aquí: http://www.microsoft.com/en-us/download/details.aspx?id=13255 Instalación utilizando el símbolo del sistema con el indicador ''/ pasivo''. En el símbolo del sistema, ejecute el siguiente comando: ''AccessDatabaseEngine_x64.exe / pasivo''

Nota: El pedido parece importar, por lo tanto, si ya tiene algo instalado, desinstálelo y siga los pasos anteriores.


Tengo el mismo error en un Windows Vista Family 64bit completamente actualizado con una aplicación .NET que he compilado solo para 32 bits: el programa está instalado en la carpeta programx86 en máquinas de 64 bits. Falla con este mensaje de error incluso con el proveedor de bases de datos de acceso 2007 instalado, con / sin el SP2 del mismo instalado, IIS instalado y el grupo de aplicaciones configurado para el soporte de la aplicación de 32 bits ... sí, he probado todas las soluciones en todas partes y aún no he tenido éxito.

Cambié mi aplicación a ACE OLE DB.12.0 porque JET4.0 estaba fallando en las máquinas de 64 bits, y no es mejor: - / El hilo más prometedor que he encontrado es este:

http://ellisweb.net/2010/01/connecting-to-excel-and-access-files-using-net-on-a-64-bit-server/

pero cuando intenta instalar el "2010 Office System Driver Beta: Data Connectivity Components" de 64 bits, le dice que no puede instalar la versión de 64 bits sin desinstalar todas las aplicaciones de oficina de 32 bits ... e instalar la versión de 32 bits de 2010 Office System Driver Beta: Data Connectivity Components no resuelve el problema inicial, incluso con "Microsoft.ACE.OLEDB.12.0" como proveedor en lugar de "Microsoft.ACE.OLEDB.14.0" que esa página (y otras) recomiendan.

Mi próximo intento será seguir esta publicación:

El problema se debe al mal sabor de OLEDB32.DLL y OLEDB32r.DLL que se registraron en el servidor. Si las versiones de 64 bits están registradas, deben ser no registradas, y luego las versiones de 32 bits registradas en su lugar. Para solucionar esto, anule el registro de las versiones ubicadas en% Program Files% / Common Files / System / OLE DB. A continuación, registre las versiones en la misma ruta, pero en el directorio% Archivos de programa (x86)%.

¿Alguien más ha tenido tantos problemas con los proveedores JET4.0 y OLEDB ACE en máquinas de 64 bits? ¿Alguien ha encontrado una solución si ninguno de los otros funciona?


Tengo un programa básico visual con Visual Studio 2008 que usa una base de datos de Access 2007 y recibía el mismo error. Encontré algunos hilos que aconsejaban cambiar la configuración de compilación avanzada a x86 que se encuentra en las propiedades de los programas si está ejecutando un sistema de 64 bits. Hasta ahora no he tenido ningún problema con mi programa desde entonces.


Ver mi publicación en un hilo similar de Stack Exchange https://.com/a/21455677/1368849

Tenía la versión 15, no 12 instalada, que descubrí al ejecutar este código de PowerShell ...

(New-Object system.data.oledb.oledbenumerator).GetElements() | select SOURCES_NAME, SOURCES_DESCRIPTION

... que me dio este resultado (he eliminado otras fuentes de datos para abreviar) ...

SOURCES_NAME SOURCES_DESCRIPTION ------------ ------------------- Microsoft.ACE.OLEDB.15.0 Microsoft Office 15.0 Access Database Engine OLE DB Provider


Solución:

¡Eso es! Gracias Arjun Paudel por el enlace. Esta es la solución que se encuentra en XNA Creator''s Club Online. Es por Stephen Styrchak.

El siguiente error me sugiere que crea que está compilando para 64 bits:

El proveedor ''Microsoft .ACE.OELDB.12.0'' no está registrado en la máquina local

No tengo una edición expresa pero sigo los pasos válidos en 2008 Express.

http://forums.xna.com/forums/t/4377.aspx#22601

http://social.msdn.microsoft.com/Forums/en-US/vbgeneral/thread/ed374d4f-5677-41cb-bfe0-198e68810805/?prof=required
- Arjun Paudel

En VC# Express , esta propiedad falta, pero aún puede crear una configuración x86 si sabe dónde buscar.

Parece una larga lista de pasos, pero una vez que sabes dónde están estas cosas, es mucho más fácil. Cualquiera que solo tenga VC# Express probablemente lo encuentre útil. Una vez que sepa sobre Configuration Manager , será mucho más intuitivo la próxima vez.

1.En VC # Express 2005, vaya a Tools -> Options .
2. En la esquina inferior izquierda del cuadro de diálogo Opciones, marque la casilla que dice "Show all settings" .
3.En la vista de árbol en el lado izquierdo, seleccione "Projects and Solutions" .
4.En las opciones de la derecha, marca la casilla que dice "Show advanced build configuraions."
5. Haga OK .
6. Ir a Build -> Configuration Manager ...
7. En la columna Plataforma al lado de su proyecto, haga clic en el cuadro combinado y seleccione "<New...>" .
8. En la "New platform" setting, choose "x86" .
9. Haga OK .
10.Haga clic en Close .
¡Aquí tienes una configuración x86! ¡Muy fácil! :-)

También recomiendo usar Configuration Manager para eliminar la plataforma Any CPU. Realmente no quieres eso si alguna vez tienes dependencias en archivos DLL nativos de 32 bits (incluso dependencias indirectas).

Stephen Styrchak | Desarrollador XNA Game Studio http://forums.xna.com/forums/p/4377/22601.aspx#22601