O provedor 'Microsoft.ACE.OLEDB.12.0' não está registrado na máquina local

Estou tentando obter dados de um arquivo do Excel em um evento de clique no botão. Minha cadeia de conexão é:

 string connString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=C:\\source\\SiteCore65\\Individual-Data.xls;Extended Properties=Excel 8.0;";

Quando clico no botão, recebi o seguinte erro:

O provedor 'Microsoft.ACE.OLEDB.12.0' não está registrado na máquina local.

Não tenho idéia de como consertar isso. Meu sistema operacional é o Windows 7.

Bem, você precisa instalá-lo. Você está procurando:

• O driver do Office System 2007: componentes de conectividade de dados .

Uma versão de 64 bits do 'Microsoft Access Database Engine 2010 Redistributable' que permitirá que você use o provedor 'Microsoft.ACE.OLEDB.12.0' está disponível aqui:
http://www.microsoft.com/en-us/ download / details.aspx? id = 13255

Se você usar o download da resposta aceita, precisará criar para o x86, como indicado em @ backtestbroker.com.

dependendo do aplicativo (32/64 bits) usando a conexão que você pode instalar

• Acessar mecanismos de 2007 (apenas 32 bits)
• Access 2010 (32 e 64 bits)
• Access 2013 runtime completo (32 e 64 bits!> 200mb)
• Tempo de execução do Access 2016
• Tempo de execução do Access 2019

Resumo:

• todos os escritórios de 2007-2016 contêm o provedor "Microsoft.ACE.Oledb.12.0"
• dependendo da arquitetura do aplicativo, escolha o mecanismo de tempo de execução apropriado (32/64) 6

• verifique seus provedores com o comando powershell do shell de 32 e 64 bits :

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

• e você verá qual provedor seu sistema pode usar

a longa história: as strings podem ser encontradas em http://live.sysinternals.com/strings.exe

por exemplo. em um sistema de 64 bits com drivers de 32 bits instalados

strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\MSO.DLL" | findstr "ACE.O"
strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE14\MSO.DLL" | findstr "ACE.O"
strings.exe -u -n 10 "c:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\MSO.DLL" | findstr "ACE.O"

mesmo no próximo escritório 2016

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\MSO.DLL
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\MSO.DLL

você encontrará as cordas

• Microsoft.ACE.OLEDB

• Microsoft.ACE.Oledb.12.0

o Office 2013 também vem com csi.dll

c:\Program Files (x86)\Common Files\microsoft shared\OFFICE15\Csi.dll
c:\Program Files\Common Files\Microsoft Shared\OFFICE15\Csi.dll

que contém o " Microsoft.ACE.OLEDB.15.0 "

e Office 2016

c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX64\Microsoft Shared\OFFICE16\Csi.dll
c:\Program Files\Microsoft Office\root\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\Csi.dll

que possui a versão " Microsoft.ACE.OLEDB.16.0 "

A primeira coisa que você precisa verificar é a configuração de compilação do seu aplicativo.

• Se você construiu seu projeto na plataforma x86 , para resolver seu problema, instale os seguintes pacotes em sua máquina:

  1. Para usar o provedor 'Microsoft.ACE.OLEDB.12.0', instale primeiro o Microsoft Access Database Engine Redistributable 2010 , esta instalação está disponível em: http://www.microsoft.com/download/en/details.aspx ? id = 13255 .

     Após a conclusão da instalação, tente executar o aplicativo, se isso resolver o problema, se não, continue com a etapa 2.

  2. Esta próxima etapa é uma solução inexplicável, que funciona para o Office 2010, mesmo que seja o Data Connectivity Components do Office 2007. Não sei ao certo por que isso funciona, mas funciona e foi comprovado que funciona em quase todos os casos. Você precisa instalar o driver do Office System 2007: componentes de conectividade de dados , esta instalação está disponível em: http://www.microsoft.com/download/en/confirmation.aspx?id=23734 .

     Após a conclusão da instalação, tente executar seu aplicativo, isso deve resolver o problema.

• Se você estiver tentando executar um aplicativo criado sob a plataforma x64 ou AnyCPU , recomendo primeiro validar se ele é executado conforme o esperado na plataforma x86. Caso não seja executado nessa plataforma x86, execute as etapas na primeira parte e valide se é executado conforme o esperado.

  Eu li que os drivers do MS Access, incluindo o driver do banco de dados OLEDB, funcionam apenas na plataforma x86 e são incompatíveis na plataforma x64 ou AnyCPU. Mas isso parece ser falso. Eu validei que meu aplicativo estava em execução ao criar o x86 e instalei o Access Database Engine usando o sinalizador passivo.

  1. Primeiro baixe o arquivo localmente Você pode baixar a instalação aqui: http://www.microsoft.com/en-us/download/details.aspx?id=13255
  2. Instalando usando o prompt de comando com o sinalizador '/ passive'. No prompt de comando, execute o seguinte comando: 'AccessDatabaseEngine_x64.exe / passive'

  Após essas duas etapas, consegui executar meu aplicativo após criar na configuração de compilação x64 ou AnyCPU. Isso pareceu resolver o meu problema.

Nota: A ordem das etapas parece fazer a diferença, portanto, siga em conformidade.

Eu recebi esse erro / exceção no Visual Studio 2010 quando alterei minha compilação na caixa de diálogo Gerenciador de Configurações de "x86" para "Qualquer CPU". Entendo que esse driver de banco de dados OLEDB funciona apenas em x86 e não é compatível com 64 bits. Alterar a configuração de compilação de volta para x86 resolveu o problema para mim.

Eu instalei os drivers da Microsoft e ainda não funcionou para mim. Então eu encontrei este post do blog que resolveu o problema. Leia aqui, caso contrário, use estas duas imagens (vinculadas a partir desse post) como o sumamary TLDR:

Se você estiver usando 64 bits, mas ainda tiver problemas, mesmo após a instalação do AccessDatabaseEngine, consulte esta postagem , resolveu o problema para mim.

Você precisa instalar este AccessDatabaseEngine

Para todos aqueles ainda afetados por isso.

Estou recebendo o erro ...

OLEDB error "The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine."

... como descrito pelo OP, Shailesh Sahu.

Eu tenho o Windows 7 de 64 bits.

Meu problema está nos scripts do PowerShell , mas estou usando uma string de conexão, semelhante à postagem do OP, por isso espero que minhas descobertas possam ser aplicadas ao C #, PowerShell e qualquer outro idioma que dependa do driver "Microsoft.ACE.OLEDB".

Segui as instruções neste tópico do fórum da Microsoft: http://goo.gl/h73RmI

Tentei primeiro instalar a versão de 64 bits e depois instalar a versão de 32 bits do AccessDatabaseEngine.exe a partir desta página http://www.microsoft.com/en-us/download/details.aspx?id=13255

Mas ainda não há alegria.

Em seguida, executei o código abaixo no PowerShell (no site do SQL Panda http://goo.gl/A3Hu96 )

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

... o que me deu esse resultado (removi outras fontes de dados por questões de concisão) ...

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

Como você pode ver, eu tenho o Microsoft.ACE.OLEDB. 15 .0 (quinze) não Microsoft.ACE.OLEDB. 12 .0 (doze)

Então, alterei minha string de conexão para 15 e funcionou.

Portanto, um snippet rápido do PowerShell para demonstrar como codificar a versão da versão virtual ...

$AceVersion = ((New-Object System.Data.OleDb.OleDbEnumerator).GetElements() | Where-Object { $_.SOURCES_NAME -like "Microsoft.ACE.OLEDB*" } | Sort-Object SOURCES_NAME -Descending | Select-Object -First 1 SOURCES_NAME).SOURCES_NAME

$connString = "Provider=$AceVersion;Data Source=`"$filepath`";Extended Properties=`"Excel 12.0 Xml;HDR=NO`";"

alterado para escolher a versão mais recente do ACE, se mais de um

Felizmente, qualquer pessoa que encontrar isso agora pode verificar para ver qual versão do OLEDB está instalada e usar o número de versão apropriado.

Embora tenham sido dadas muitas respostas, o problema que encontrei ainda não foi mencionado.

• Meu cenário: Aplicativo de 64 bits, Win10-64, Office 2007 de 32 bits instalado.

• A instalação do AccessDatabaseEngine.exe de 32 bits , baixada do MS, informa que foi bem-sucedida, mas NÃO está instalada, conforme verificado com o Powershell Script de uma das postagens acima aqui.

• A instalação do instalador de 64 bits AccessDatabaseEngine_X64.exe relatou uma mensagem de erro chocante:

A solução muito simples foi encontrada aqui em um site da Autodesk. Basta adicionar o parâmetro / passive à string da linha de comando, assim:

AccessDatabaseEngine_X64.exe / passive

Instalação bem-sucedida, o driver OleDb funcionou.

Os arquivos do Excel que estou processando com o OleDb são do tipo xlsx, produzidos com o EPPlus 4.5 e modificados com o Excel 2007.

Você precisa alterar a Plataforma de Solução de "Qualquer CPU" para "x86" ou "x64" com base na instalação da empresa.

Os passos são dados abaixo:

1. Clique com o botão direito do mouse no arquivo Solution no Solution Explorer:

   2. Clique no Gerenciador de configuração.

   3. Clique no menu suspenso Active Platform, se o x86 já estiver lá, selecione-o e clique em Novo.

   4. Selecione x86 ou x64 no novo menu suspenso da plataforma:

Compile e execute seu aplicativo.

Se o "AccessDatabaseEngine" instalado ainda não ajudar, abaixo está a solução:

Você precisa alterar a Plataforma de solução ativa de "Qualquer CPU" para "x86".

O provedor OLEDB não está registrado na máquina local

From CodeProject.com

Consegui corrigir isso seguindo as etapas deste artigo: http://www.mikesdotnetting.com/article/280/solved-the-microsoft-ace-oledb-12-0-provider-is-not-registered- na máquina local

O ponto chave para mim foi o seguinte:

Ao depurar com o IIS,

Por padrão, o Visual Studio usa a versão de 32 bits. Você pode alterar isso no Visual Studio, vá em Ferramentas »Opções» Projetos e soluções »Projetos da Web» Geral e escolha

"Use a versão de 64 bits do IIS Express para sites e projetos"

Depois de marcar essa opção e depois definir o destino da plataforma do meu projeto para "Qualquer CPU" (eu o havia definido como x86 em algum lugar do processo de solução de problemas), consegui superar o erro.

Se você estiver depurando um projeto da web, verifique se o IIS Express está sendo executado em 32 ou 64 bits, dependendo das configurações do seu projeto.

Vamos para

Ferramentas> Opções> Projetos e soluções> Projetos da Web

e a partir daí marque (ou desmarque) a opção 'Usar versão de 64 bits do IIS Express ...'

Primeiro verifique qual versão do microsoft.ace.oledb.12.0 está instalada no seu sistema.

Verifique no caminho C: \ Arquivos de programas \ Arquivos comuns \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL - 64 bits está instalado

Verifique no caminho C: \ Arquivos de programas (x86) \ Arquivos comuns \ Microsoft Shared \ OFFICE14 \ ACEOLEDB.DLL --x86 bits está instalado

Se (x86) estiver instalado, use o gerenciador de configuração, altere a plataforma de solução para x86, para x64, altere para x64.

Se não estiver disponível, instale usando o link abaixo

https://www.microsoft.com/en-us/download/details.aspx?id=23734

syp_dino,

A solução para mim, como você sugeriu para o erro "O provedor Microsoft.ACE.OLEDB.12.0 'não está registrado na máquina local", é alterar a Plataforma de Solução Ativa de "Qualquer CPU" para "x86".

Quando eu executei essas etapas, reconstruí a solução, peguei o EXE e coloquei na rede, tudo funcionou perfeitamente na máquina Windows 7 de 64 bits.

Eu tive esse problema ao tentar importar dados de um arquivo do Excel (xlsx) para um banco de dados do SQL Server usando o SSMS 2014.

A instalação do driver do Office System 2007: componentes de conectividade de dados fez o truque para mim.

Eu enfrentei esse mesmo problema. Vá para Propriedades da solução e altere Qualquer CPU para x86, acho que ele fará o trabalho.

execute estas 2 etapas: 1. neste menu: projeto -> propriedades do seu projeto ... -> Construção: desmarque "prefira 32 bits" 2. in connectionString: escreva cuotes antes e depois das propriedades estendidas, assim: Propriedades estendidas = ' Excel 12.0 Xml; HDR = SIM '

                var fileName = string.Format("{0}", openFileDialog1.FileName);
            //var connectionString = string.Format("Provider=Microsoft.Jet.OLEDB.4.0; data source={0}; Extended Properties=Excel 8.0;", fileName);
            var connectionString = string.Format("Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0}; Extended Properties='Excel 12.0 Xml;HDR=YES'", fileName);
            var adapter = new OleDbDataAdapter("SELECT * FROM [Sheet1$]", connectionString);
            var ds = new DataSet();

            adapter.Fill(ds, TableNmae);

            DataTable data = ds.Tables[TableNmae];
            dg1.DataSource = data;

Essas configurações funcionaram em janeiro de 2020 na minha nova máquina:

(1 - apenas x64) Windows 10 x64, Office 365 x64, AccessDatabaseEngine_x64 2016 instalado com argumento / passivo, configurações de compilação do VStudio definidas explicitamente para x64, com a seguinte cadeia de conexão: Provider = Microsoft.ACE.OLEDB.16.0; Origem de dados = D: ... \ MyDatabase.accdb

(2 - x64 ou x32) Windows 10 x64, Office 365 x64, AccessDatabaseEngine_x64 2016 instalado com argumento / passivo, PLUS AccessDatabaseEngine 2010 (32 bits) instalado com argumento / passivo, configurações de compilação do VStudio definidas como AnyCPU, com a seguinte cadeia de conexão: Provider = Microsoft.ACE.OLEDB.16.0; Origem de dados = D: ... \ MyDatabase.accdb

(Somente 3 x32) Windows 10 x64, Office 365 x32, AccessDatabaseEngine 2010 (32 bits) instalado com argumento / passivo, configurações de compilação do VStudio definidas como x86, com a seguinte cadeia de conexão: Provider = Microsoft.ACE.OLEDB.12.0; Origem de dados = D: ... \ MyDatabase.accdb

NOTAS DE FALHA

O uso do provedor ACE.OLEDB.12.0 x64 na cadeia de conexão falhou apenas com o AccessDatabaseEngine_x64 2016 instalado como acima em (1).

O uso de AnyCPU no visual studio build settings falhou em (1). É necessário definir x64. Talvez isso ocorra porque AnyCPU significa que o Vstudio deve ver um provedor x32 ACE.OLEDB.nn.0 em tempo de compilação.

O mecanismo x32 / passivo ACE.OLEDB.12.0 2016 NÃO seria instalado quando vislumbrasse aplicativos x64. (O instalador do ACE.OLEDB.12.0 2010 x32 / passive funcionou.)

CONCLUSÕES

Para usar as configurações de compilação x64, você precisa do mecanismo de banco de dados x64 2016 E do provedor de cadeia de conexão ACE.OLEDB.16.0 E das configurações explícitas de compilação x64 para trabalhar com o Office 365 em janeiro de 2020. O uso da opção / passive facilita as instalações. Crédito para quem postou essa dica!

Para usar o AnyCPU, eu precisava ter os mecanismos ACE.OLEDB.12.0 2010 x32 e ACE.OLEDB.16.0 x64 instalados. Dessa forma, o Vstudio pode ver os mecanismos x32 e x64 no momento da compilação "AnyCPU". Eu poderia alterar a cadeia de conexão do provedor para ACE.OLEDB.12.0 para operação x32 ou para ACE.OLEDB.16.0 para operação x64. Ambos funcionaram bem.

Para usar as configurações de compilação do x86, é necessário ter o mecanismo de banco de dados x32 de 2010 E o provedor de cadeia de conexão ACE.OLEDB.12.0 E as configurações explícitas de compilação do x86 para trabalhar com o Office 365 x32 em janeiro de 2020.

Eu tenho um problema semelhante quando estamos lendo o arquivo Excel.

Histórico do problema:

Recentemente, migramos nosso aplicativo de 32 bits para 64 bits devido ao requisito de memória. Para isso, migramos nossas janelas 7 de 32 bits para 64 bits. Mas ainda instalamos o escritório de 32 bits em nossas máquinas.

porque, disso, tivemos esse problema ao importar dados do Excel para o aplicativo.

Solução,

Baixei a versão de 64 bits do http://www.microsoft.com/en-us/download/details.aspx?id=13255 e instalei com o argumento como,

AccessDatabaseEngine_x64.exe / passivo

Sem qualquer alteração de código, meu problema é resolvido.

Nota:

No SO de 64 bits e no escritório de 64 bits, minha funcionalidade estava funcionando bem sem essa correção. Essa correção é necessária apenas enquanto o aplicativo estiver em execução de 64 bits no sistema operacional de 64 bits, que possui o escritório de 32 bits instalado.

Basta baixar e instalar o seguinte mecanismo do Access DB (X86 ou X64: conforme a configuração da sua máquina) e ver a mágica :)

https://www.microsoft.com/en-us/download/confirmation.aspx?id=13255

Eu segui as instruções estabelecidas por outros; instalar esse patch, instalar esse patch e o Microsoft Access Database Engine 2010.

Meu problema foi que eu estou usando a mesma biblioteca (linq2sql) em 2 sites na minha máquina; 1 funciona e 1 não.

Eventualmente, descobri que tinha que "ativar aplicativos de 32 bits" nas configurações avançadas do pool de aplicativos para o site que não funcionava.

Tudo funciona bem agora.

também pode tentar estas etapas

No SQL Server, 1.Abra um banco de dados 2.Clique na opção 'Servidor Obtido' 3.Clique em 'Servidores Vinculados' 4.Clique em 'Provedores' 5.Clique em 'Microsoft.ACE.OLEDB.12.0' 6.Desmarque todas as opções e feche

Lembre-se de instalar o AccessDatabaseEngine no servidor para aplicativo da web.

Eu tive o mesmo problema, mas, neste caso, o microsoft-ace-oledb-12-0-provider já estava instalado na minha máquina e funcionando bem para outros aplicativos desenvolvidos.

A diferença entre o aplicativo e o que eu tive o problema foi que os aplicativos antigos estavam sendo executados no " IIS local ", enquanto o aplicativo com erro estava no " IIS Express (executando no Visual Studio"). Então o que eu fiz foi-

1. Clique com o botão direito do mouse no nome do projeto.
2. Vá para Propriedades
3. Vá para a guia Web à direita.
4. Em Servidores, selecione IIS Local e clique no botão Criar Diretório Virtual.
5. Execute o aplicativo novamente e funcionou.

Eu já tinha o Microsoft Access Database Engine Redistributable 2010 instalado na minha máquina, mas ainda estava recebendo o erro do Microsoft ACE OLEDB Provider .

Lembrei-me de que havia atualizado para o Office 2016 recentemente; portanto, devo tentar reinstalar o Microsoft Access Database Engine 2010 Redistributable . E isso corrigiu o problema na minha máquina.

Portanto, se você atualizou para uma versão diferente do MS Office ou mesmo reparou / reinstalou o MS Office, tente reinstalar o Microsoft Access Database Engine 2010 Redistributable antes de perder tempo encontrando outras correções. Boa sorte!

1.) Verifique sua cadeia de conexão com o ConnectionStrings.com .

2.) Verifique se você tem o mecanismo de banco de dados correto instalado. Esses foram os dois mecanismos de banco de dados que me ajudaram.

Mecanismo de banco de dados do Microsoft Access 2010 redistribuível

Driver do sistema Office 2007: componentes de conectividade de dados

3.) Pode haver um problema com a plataforma de destino da compilação sendo "Qualquer CPU", pode ser necessário "X86" (Propriedades, Compilação, Destino da Plataforma).

Se você receber esse erro ao tentar usar o ACE em um aplicativo ASP.NET, a causa mais provável é que você instalou uma das versões de 32 bits. Por padrão, o IIS em um sistema operacional de 64 bits executará aplicativos em um processo de trabalho de 64 bits. Processos de 64 bits não podem carregar DLLs de 32 bits. Quando uma chamada é feita ao provedor ACE, o processo de 64 bits tenta localizar uma DLL de 64 bits. Se não existir, você receberá a mensagem de erro que trouxe você aqui.

Nesse caso, você tem duas opções. Primeiro, você pode instalar a versão de 64 bits de 2010. Se você possui a versão de 32 bits de 2007 instalada, pode simplesmente instalar a versão de 64 bits de 2010 ao lado. Se você possui a versão de 32 bits do 2010 instalada, é necessário desinstalá-la, fazer o download e instalar a versão de 64 bits. Você não pode ter as versões de 32 e 64 bits do provedor 2010 instaladas ao mesmo tempo. Se você estiver executando a instalação em sua máquina de desenvolvimento, também poderá ser limitado pelo bit-ness de qualquer instalação existente do Office.

A segunda opção é alterar o pool de aplicativos no IIS para habilitar aplicativos de 32 bits. Se você estiver usando a versão completa do IIS, poderá usar a ferramenta de gerenciamento para fazer isso (Painel de controle »Ferramentas administrativas» Gerenciador do Internet Information Services (IIS)).

Para mais compreensão, consulte o link abaixo

Eu recebi esse erro ao importar dados de um arquivo do Excel para o MS-SQL. O provedor já estava instalado (64 bits) e isso me surpreendeu por que não funcionou. Então, tudo o que fiz foi localizar o aplicativo Import / Export usado aqui, ou seja, o .EXE. E eu achei isso em

C: \ Arquivos de programas \ Microsoft SQL Server \ 130 \ DTS \ Binn \ DTSWizard.exe

Em seguida, executei o .exe diretamente para executar a importação de dados. E funcionou!

Isso funcionou para mim agora.

1. Visite esta página e faça o download do pacote apropriado para o seu computador (AccessDatabaseEngine.exe ou AccessDatabaseEngine_X64.exe)
2. Instale isso.
3. Aproveite ... Seus códigos estão funcionando agora ...

Mas para o seu pacote de aplicativos, você pode usar qualquer uma das seguintes soluções:

4. Vá em "C: \ Arquivos de Programas (x86) \ Arquivos Comuns \ microsoft shared" ou "C: \ Arquivos de Programas \ Arquivos Comuns \ Microsoft Shared" e coloque o diretório "OFFICE14" no mesmo local do arquivo do pacote.

Ou

4. Anexe dois projetos (no item1) no seu pacote de instalação.