Il provider Microsoft.Jet.OLEDB.4.0 non è registrato sul computer locale

Ho creato un’applicazione per Windows sviluppata in .NET 3.5 in un server Windows 2008 a 32 bit. Quando viene distribuita l’applicazione in un server a 64 bit, viene visualizzato l’errore “Il provider Microsoft.Jet.OLEDB.4.0” non è registrato sul computer locale “.

Quindi, come soluzione a questo problema, ho modificato la proprietà di costruzione del progetto in X86, in modo che venga creata in modalità a 32 bit e ricostruisca il progetto nella macchina a 32 bit. Ma lo stesso progetto utilizza altri driver DB (DB2, SQL ecc.) Per connettersi ad altri database. Pertanto, quando ho distribuito la mia app di nuovo nel sistema operativo a 64 bit, viene generata l’eccezione “Tentativo di caricare un assembly a 64 bit su una piattaforma a 32 bit”.

Sto usando il driver Microsoft.Jet.OLEDB.4.0 per leggere e scrivere in Excel (.xls)

Ho trovato una soluzione per questo problema. Il problema che ho descritto nella mia domanda si è verificato essenzialmente a causa dell’incompatibilità del driver Microsoft.Jet.OLEDB.4.0 nel sistema operativo a 64 bit.

Quindi, se stiamo usando il driver Microsoft.Jet.OLEDB.4.0 in un server a 64 bit, dobbiamo forzare la nostra applicazione a compilare in modalità a 32 bit (questa è la risposta che ho trovato quando ho fatto una ricerca approfondita per questo problema noto ) e questo causa l’interruzione di altre parti del mio codice.

Fortunatamente, ora Microsoft ha rilasciato un driver per Office System 2010 compatibile con 64 bit che può essere utilizzato come sostituto del tradizionale driver Microsoft.Jet.OLEDB.4.0. Funziona sia su server a 32 bit che a 64 bit. L’ho usato per la manipolazione dei file di Excel e ha funzionato bene per me in entrambi gli ambienti. Ma questo driver è in BETA .

È ansible scaricare questo driver da Microsoft Access Database Engine 2010 Redistributable

Se il problema persiste in ASP.NET, tutto quello che dovevo fare era cambiare l’impostazione “Abilita applicazioni a 32 bit” su True, nelle Impostazioni avanzate per il pool di applicazioni.

Ho lo stesso problema

Il provider Microsoft.Jet.OLEDB.4.0 non è registrato sul computer locale

Ho applicato la risposta di Neo ma non ha funzionato fino a quando non ho cambiato il provider in “Provider = Microsoft.ACE.OLEDB.12.0;” nella stringa di connessione.

Spero che questo possa aiutare se qualcuno affronta lo stesso problema.

Ho lo stesso messaggio, ho una pagina web con do su visual studio 2010, ho letto un file.xls su quella pagina, nel mio progetto visual non ha alcun problema, quando lo metto sul mio IIS locale mi getta un ‘Microsoft .Jet.OLEDB.4.0 ‘provider non è registrato sul computer locale’ , ho risolto il problema dopo aver seguito questa procedura,

1.-Apri IIS
2.-Cambia l’appPool in Impostazioni avanzate
3.-true per abilitare l’applicazione a 32 bit.

e questo è tutto

ps.Ho cambiato Configuration Manager in X86 su Active Solution Platform

So che sono domande piuttosto vecchie e molte persone hanno risposto. ma sto riassumendo le cose per capire:

Se l’estensione del file è xls e il sistema operativo è a 32 bit, solo tu puoi utilizzare ” Microsoft.Jet.OLEDB.4.0 “. Microsoft non ha rilasciato la versione a 64 bit di questo driver.

Se l’estensione del file è xlsx o OS è 64 bit, è necessario utilizzare ” Microsoft.ACE.OLEDB.12.0 “. L’applicazione compilata in modalità 32/64 bit non influisce sulla selezione del driver.

Installa sempre il driver a 64 bit di Microsoft.ACE.OLEDB.12.0 su OS a 64 bit. Se hai già installato Office 32 bit, devi eseguire il driver da cmd con / passive. Questo hack funziona solo fino a Office 2013, Microsoft ha interrotto questa soluzione alternativa da Office 2016 per i driver Microsoft.ACE.OLEDB.16.0.

 AccessDatabaseEngine_x64.exe /passive 

Scarica i driver Microsoft.ACE.OLEDB.12.0

 private void ProcessFile(string path) { string connString = string.Empty; if (Path.GetExtension(path).ToLower().Trim() == ".xls" && Environment.Is64BitOperatingSystem == false) connString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" + path + ";Extended Properties=\"Excel 8.0;HDR=Yes;IMEX=2\""; else connString = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + path + ";Extended Properties=\"Excel 12.0;HDR=Yes;IMEX=2\""; } 

Se l’applicazione è compilata con il flag AnyCPU, cercherà i driver di accesso a 64 bit sul sistema operativo a 64 bit e i driver di accesso a 32 bit sul sistema operativo a 32 bit.

Se l’applicazione viene eseguita su localIIS, è ansible risolvere questo problema triggersndo le applicazioni a 32 bit nelle Impostazioni avanzate di AppPool

inserisci la descrizione dell'immagine qui

Ho avuto lo stesso problema. Ho cambiato la configurazione dell’applicazione in x86 , quindi ha funzionato!

Ho appena cambiato la mia proprietà del progetto in formato x64

Progetto —> Proprietà —> Build —> Target Framework —> X64

Ho riscontrato questo problema con la mia applicazione desktop (il provider “Microsoft.Jet.OLEDB.4.0” non è registrato sul computer locale). Non ho avuto la possibilità di creare un’app a 32 bit. Sperando che questo aiuti gli altri nella stessa situazione.

Ho fatto quanto segue e il problema è andato via:

  1. Installata la versione a 64 bit di Microsoft Access Database Engine 2010 Redistributable , come suggerito da neo

  2. Modificato il mio provider in Microsoft.ACE.OLEDB.12.0

Modifica nelle impostazioni avanzate del pool di applicazioni Impostazioni IIS. Abilita l’applicazione a 32 bit

Basta cambiare la proprietà in base al tuo computer e tutti hanno fatto 🙂

Progetto —> Proprietà —> Build —> Target Framework —> X64

o

Progetto —> Proprietà —> Build —> Target Framework —> X86

Ho cambiato la mia stringa di connessione da

var myConnectionString = string.Format (“Provider = Microsoft.Jet.OLEDB.4.0; Data Source = {0}; Persist Security Info = True; Jet OLEDB: Database Password =;”, gisdbPath);

a questa:

var myConnectionString = string.Format (“Provider = Microsoft.Jet.OLEDB.4.0; Mode = Share Nega None; Data Source = {0}; id utente = Admin; password =;”, gisdbPath);

Funziona da me mai chiesto di Microsoft.Jet.OLEDB.4.0 ‘registrato.

Abbiamo riscontrato questo problema nell’app desktop.

Dev Environment: Windows 7 Ultimate – 64 bit .Net Framework 4.5 Provider = Microsoft.Jet.OLEDB.4.0

È stato risolto cambiando il target della piattaforma su X86 da qualsiasi CPU. Proprietà del progetto >> Build >> Target della piattaforma.

inserisci la descrizione dell'immagine qui

Non c’è in effetti nessuna versione a 64 bit di Jet – e nessun piano (apparentemente) per produrne uno.

Potresti essere in grado di utilizzare il driver ACE a 64 bit: http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=23734

  • ma non ho idea di come funzioni se dovessi tornare a Jet per le tue app a 32 bit.

Tuttavia, potresti essere in grado di passare il progetto a 32 bit nella versione Express (non ho ancora provato e non ho più installato 2008 in nessun altro)

Forse è il momento di rompere completamente i database di Access, mordere il proiettile e andare invece al server SQL?

Sto usando VS2013 per Winforms, la soluzione sotto ha funzionato per me.

Nelle versioni precedenti di IIS, non troverai le Advance Settings per abilitare Enable 32-bit Applications devi eseguire i seguenti comandi:

cscript% SYSTEMDRIVE% \ inetpub \ adminscripts \ adsutil.vbs SET W3SVC / AppPools / Enable32bitAppOnWin64 1

e

% SYSTEMROOT% \ Microsoft.NET \ Framework \ v2.0.50727 \ aspnet_regiis.exe -i

Riferimento: qui

Ho riscontrato la stessa eccezione durante l’esecuzione di “SQL Server 2014 Import and Export Data (64-bit)” sul mio Windows 8.1.

Per risolvere il problema questo problema ho fatto quanto segue

ha iniziato l’importazione e l’esportazione dei dati di SQL Server 2014 (a 32 bit) anziché a 64 bit e funziona per me. Non ho cambiato alcuna impostazione di IIS e non ho installato alcun software aggiuntivo.

So che ho questo problema più e più volte quando distribuisco la mia applicazione su un nuovo server perché sto usando questo driver per connettermi a un file Excel. Quindi ecco cosa sto facendo ultimamente.

C’è un Windows Server 2008 R2, installo i driver Access per una macchina x64 bit e mi sbarazzo di questo messaggio, il che mi rende molto felice solo per incontrarne un’altra.

Questo qui sotto funziona splendidamente sulla mia macchina di sviluppo ma sul server mi dà un errore anche dopo aver installato i driver ODBC più recenti, il che penso sia questo il problema, ma questo è il modo in cui l’ho risolto.

 private const string OledbProviderString = "Provider=Microsoft.Jet.OLEDB.4.0;Data Source=|DataDirectory|\\OlsonWindows.xls;Extended Properties=\"Excel 8.0;HDR=YES\""; 

Sostituisco con il nuovo provider come questo di seguito:

 private const string OledbProviderString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\OlsonWindows.xlsx;Extended Properties='Excel 12.0;HDR=YES;';"; 

Ma mentre lo faccio, c’è una cosa che dovresti notare. Utilizzando l’estensione del file .xlsx e la versione di Excel è 12.0.

Dopo aver visualizzato questo messaggio di errore Errore: “Imansible trovare ISAM installabile” , decido di modificare le cose un po ‘come di seguito:

 private const string OledbProviderString = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=|DataDirectory|\OlsonWindows.xls;Extended Properties='Excel 8.0;HDR=YES;';"; 

e sì, ho finito con quella cosa brutta, ma qui ho ricevuto un altro messaggio Il motore di database di Microsoft Access non può aprire o scrivere nel file ‘time_zone’. È già aperto esclusivamente da un altro utente, o è necessaria l’authorization per visualizzare e scrivere i suoi dati. che mi dice che non sono lontano dal risolverlo.

Forse c’è un altro processo che ha aperto il file nel frattempo e tutto ciò che devo fare è un riavvio e tutto inizierà in modo fluido come previsto.

Sebbene una soluzione più ottimale sia semplicemente ricompilare come suggerito sopra, richiede l’accesso al codice sorgente. Nel mio caso, avevo solo l’exe finito e dovevo usare questa soluzione. Utilizza CorFlags.exe .Net per modificare le caratteristiche di caricamento dell’applicazione.

  1. Scarica il .Net Framework SDK (Personalmente ho usato 3.5 , ma la versione utilizzata dovrebbe essere pari o superiore al .Net richiesto per la tua applicazione.
  2. Durante l’installazione, tutto ciò che serve è CorLibs.exe , quindi basta controllare gli strumenti di sviluppo di Windows .
  3. Dopo l’installazione, trova CorFlags.exe . Per la mia installazione di .Net Framework 3.5 SDK, era in C:\Program Files\Microsoft SDKs\Windows\v7.0\Bin .
  4. Aprire un prompt dei comandi e digitare path/to/CorFlags.exe path/to/your/exeFile.exe /32Bit+ .

Hai finito! Ciò imposta i flag di avvio per il programma in modo che inizi nella modalità WOW64 a 32 bit e possa quindi accedere a microsoft.jet.oledb.4.0.

Non esiste un provider a 64 bit per Jet. Se si desidera supportare più sorgenti DB, tra cui Jet in Excel, è necessario almeno quella parte dell’applicazione per l’esecuzione in un processo a 32 bit.

L’errore che ottieni quando compili x86 è un po ‘strano. Non riesco a vedere come si finirebbe per fare riferimento a assembly 64 bit in questo caso.

La soluzione più semplice è entrare nelle proprietà del progetto e impostare il target di compilazione su x86 da qualsiasi CPU.