none
ODBC Excel Driver Stopped Working with "Unexpected error from external database driver (1). (Microsoft JET Database Engine)"

    Question

  • Overnight all of the sudden I cannot import using the Excel Driver.  It was working fine yesterday.  Nothing has changed on my end including the file we import.  The only thing I can think of is the server may have had a windows update.

    This it the driver details we are using OleDB:

    Driver={Microsoft Excel Driver (*.xls)};
    DriverId=790;
    Dbq=[FilePath];
    DefaultDir=[FolderPath];

    I get this error returned from the ASP.Net application:

    ERROR [HY000] [Microsoft][ODBC Excel Driver] Reserved error (-5016); there is no message for this error. ERROR [01000] [Microsoft][ODBC Excel Driver]General Warning Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x1644 Thread 0x3e70 DBC 0x4c51fc4 Excel'. ERROR [IM006] [Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed ERROR [01000] [Microsoft][ODBC Excel Driver]General Warning Unable to open registry key 'Temporary (volatile) Jet DSN for process 0x1644 Thread 0x3e70 DBC 0x4c51fc4 Excel'. ERROR [HY000] [Microsoft][ODBC Excel Driver] Reserved error (-5016); there is no message for this error.

    I then remoted into the server and tried imported directly via SQL Server Management Studio and got the following:


    Unexpected error from external database driver (1). (Microsoft JET Database Engine)

    ------------------------------
    Program Location:

       at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)
       at System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
       at System.Data.ProviderBase.DbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
       at System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)
       at System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
       at System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
       at System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
       at System.Data.ProviderBase.DbConnectionInternal.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
       at System.Data.OleDb.OleDbConnection.Open()
       at Microsoft.SqlServer.Dts.DtsWizard.DTSWizard.GetOpenedConnection(WizardInputs wizardInputs, String connEntryName)
       at Microsoft.SqlServer.Dts.DtsWizard.Step1.OnLeavePage(LeavePageEventArgs e)

    Please help,

    John

    Inology

    Thursday, October 12, 2017 1:12 AM

All replies

  • I found a work around by changing my connection string to the following:

    Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};
    DriverId=790;
    Dbq=[FilePath];
    DefaultDir=[FolderPath];



    John Inology

    • Proposed as answer by Brian Lowery Monday, October 23, 2017 4:05 PM
    • Unproposed as answer by Brian Lowery Monday, October 23, 2017 4:05 PM
    Thursday, October 12, 2017 5:21 AM
  • Unexpected error from external database driver (1). (Microsoft JET Database Engine)

    Hi John,

    Thank you for posting here.

    According to the message above, you said that your server had been updated. For this purpose, could you please provide update log , or the list of windows update patches which have been applied to the sever, then tell us the version of operation system,  so that we could determine which situation you have come across.

    Best Regards,

    Will



    MSDN Community Support
    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    • Edited by Will_Kong Thursday, October 12, 2017 7:56 AM
    Thursday, October 12, 2017 7:56 AM
  • Hi Will,

    I have the same problem after the October 10 update.

    When use Provider=Microsoft.Jet.OLEDB.4.0 to connect excel file will get Unexpected error from external database driver (1).

    Rick

    Thursday, October 12, 2017 8:26 AM
  • Hi,

    We've got the same problem when trying to access Excel files using an ADO Connection in Delphi with the following connection string:

    Provider=Microsoft.Jet.OLEDB.4.0;Data Source=C:\MyExcel.xls;Extended Properties="Excel 8.0;HDR=Yes;IMEX=1";

    The suggested workaround doesn't work for us, we get the following error:

    [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified

    This is a major problem for us, and we really need a solution. Does anybody have another workaround? Thanks in advance,

    Bram

    Thursday, October 12, 2017 9:02 AM
  • Exactly the same problem here after the KB4041676 update.

    I'm receiving many bug reports from my customers.

    Suggested workaround doesn't work.

    Part of my SQL.LOG:

    -------------   2360-198c ENTER SQLDriverConnectW 
    HDBC                0x0734B810
    HWND                0x000C0662
    WCHAR *             0x66D622F0 [      -3] "******\ 0"
    SWORD                       -3 
    WCHAR *             0x66D622F0 
    SWORD                       -3 
    SWORD *             0x00000000
    UWORD                        0 <SQL_DRIVER_NOPROMPT>

    -------------   2360-198c EXIT  SQLDriverConnectW  with return code -1 (SQL_ERROR)
    HDBC                0x0734B810
    HWND                0x000C0662
    WCHAR *             0x66D622F0 [      -3] "******\ 0"
    SWORD                       -3 
    WCHAR *             0x66D622F0 
    SWORD                       -3 
    SWORD *             0x00000000
    UWORD                        0 <SQL_DRIVER_NOPROMPT>

    DIAG [S1000] [Microsoft][Driver ODBC Excel] Errore riservato (-5016); non ci sono messaggi per questo errore. (-5016) 

    DIAG [01000] [Microsoft][Driver ODBC Excel]Avviso generico. Impossibile aprire la chiave 'Temporary (volatile) Jet DSN for process 0x2360 Thread 0x198c DBC 0x734c67c Excel' del Registro di sistema. (1) 

    DIAG [IM006] [Microsoft][Driver Manager ODBC] Funzione SQLSetConnectAttr del driver non riuscita. (0) 

    Thursday, October 12, 2017 9:11 AM
  • I have an extremely similar issue, though I am using Jet 4.0 to import data from an Excel 2003 spreadsheet in SQL server:

    SELECT * INTO testtable FROM OPENROWSET(
    'Microsoft.Jet.OLEDB.4.0',
    'Excel 8.0;Database=C:\full path to spreadsheet\spreadsheet.xls',
    'SELECT * FROM [Sheet1$]'
    )

    The update to .NET which has gone out this patch Tuesday has broken this process on both Windows 10 & our remaining Windows 7 machines with the following error messages:

    The OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)" reported an error. The provider did not give any information about the error.
    Cannot initialize the data source object of OLE DB provider "Microsoft.Jet.OLEDB.4.0" for linked server "(null)".

    Having scoured the web for possible solutions, it seems related to a permissions issue for the temporary dsn files that Jet uses; however, all the previous instances' solutions did not help in my case. We are still frantically searching for a solution as this breaks a couple of very important, time sensitive processes for us; I'll update here if I find anything salient.

    Hopefully searching for the above error and implementing the security updates on folders for the network services etc. will aid you in fixing your problem (even though it did not for me).

    Thursday, October 12, 2017 9:19 AM
  • Hi Rick

    We had the same problem as you and our whole solution stopped working. The following worked for me:

    Instead of :Provider=Microsoft.Jet.OLEDB.4.0;Data Source=" & dataSource & ";" & "Extended Properties="Excel 8.0;HDR=No";

    I changed it to "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & dataSource & ";" & "Extended Properties="Excel 12.0;HDR=No";

    The solution then worked as before!

    Mircosoft updates hey!!

    Thanks Neil

    Thursday, October 12, 2017 9:24 AM
  • I tried using ACE.OLEDB.12.0 for <g class="gr_ gr_64 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="64" id="64">xls</g> files, it works.

    I was using ACE.OLEDB.12.0 for <g class="gr_ gr_115 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" data-gr-id="115" id="115">xlsx</g> files, and Jet.OLEDB.4.0 for <g class="gr_ gr_158 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling ins-del multiReplace" data-gr-id="158" id="158">xls</g> files.

    After October 10th update, Je.OLEDB.4.0 is giving this error so I started using ACE.OLEDB.12.0 for both <g class="gr_ gr_254 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" data-gr-id="254" id="254">xls</g> and <g class="gr_ gr_265 gr-alert gr_spell gr_inline_cards gr_run_anim ContextualSpelling" data-gr-id="265" id="265">xlsx</g> files.  No <g class="gr_ gr_333 gr-alert gr_gramm gr_inline_cards gr_run_anim Style multiReplace" data-gr-id="333" id="333">problem  so</g> far.

    Thursday, October 12, 2017 9:26 AM
  • The fact that you can use ACE instead is fine for most use cases; the problem we have is with corporate customers who don't want to install the Access database components so we have maintained using Jet for imports of Excel 2003 and below as it is built-in so to speak.

    By the way, if people need the downloads for the components (including ACE), they are available here:

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

    2010 (x32 & x64): https://www.microsoft.com/en-in/download/details.aspx?id=13255

    Thursday, October 12, 2017 10:01 AM
  • This is a big problem introduced by a recent update of Microsoft Office. I have the same problem. 
    Thursday, October 12, 2017 10:34 AM
  • As a temporary fix, if you are on Windows 7 you can roll back the .Net update to enable you to work until a more satisfactory solution is available.
    Thursday, October 12, 2017 10:55 AM
  • We have the same problem with Windows Update KB4041676 on Windows 10 or KB4041681 on Windows 7.

    MS Dao or ODBC database driver can not open any Excel file. 

    A lot of our users can not work.



    Thursday, October 12, 2017 11:03 AM
  • Hi,

    This is error in Windows update KB4041681

    Temporary solution is uninstall KB4041681.

    Microsoft should fix is ASAP...

    We have big number of reports from customers about this ERROR: all office version, all Windows version..

    Pawel Pelc

    www.LoMag.eu


    Pawel

    Thursday, October 12, 2017 12:16 PM
  • The temporary solution suggested above has not worked for me... i.e. to uninstall KB4041681
    Thursday, October 12, 2017 12:57 PM
  • Same here - KB4041681 and KB4041678 have to be deinstalled.

    Microsoft should really fix this.

    Thursday, October 12, 2017 1:43 PM
  • Same here - KB4041681 and KB4041678 have to be deinstalled.

    Microsoft should really fix this.


    Yes, I did this earlier and that did the trick for me.  Uninstalling KB4041681 alone was not enough.  After I uninstalled both KB4041681 and KB4041678 the problem seems to have gone away, for now.
    Thursday, October 12, 2017 1:54 PM
  • Excelente me Funciono también a mi yo tengo un sistema en ASP y no permitía leer los excel que se subían al sistema, hice lo que indicaste y funciono genial 

    ahora a esperar si sale alguna solución formal para esto , muchas gracias por tu aporte

    Thursday, October 12, 2017 2:41 PM
  • Same issue here.
    Using an external desktop aaplication to export data through ODBC into an Excel file.

    Should uninstall KB4041678 and KB4041681 in Windows 7. Also uninstall KB4041676 in Windows 10.

    Thursday, October 12, 2017 4:00 PM
  • I've the same problem on a Windows Server 2008.

    But I don't have the KB4041678-681-676 installed.

    The error was: [Microsoft][Driver ODBC Excel] Reserved error (-5016).

    Any suggestions ?

    • Proposed as answer by Francis Faure Tuesday, October 17, 2017 11:44 AM
    • Unproposed as answer by Francis Faure Tuesday, October 17, 2017 11:44 AM
    Thursday, October 12, 2017 4:08 PM
  • Fixed the issue by rolling back one of the larger Windows drivers installed on 10/10/17. I did not make note of the specific ID.
    • Proposed as answer by tandori Thursday, October 12, 2017 6:29 PM
    • Unproposed as answer by tandori Thursday, October 12, 2017 6:29 PM
    • Proposed as answer by tandori Thursday, October 12, 2017 6:31 PM
    • Unproposed as answer by tandori Thursday, October 12, 2017 6:31 PM
    Thursday, October 12, 2017 4:56 PM
  • When is this going to be fixed? This is related to recent updates made to my machine yesterday (Oct 11) on Windows 8.1 KB4041693 and KB4043763.  This is severely impacting my workflow and the workflows of others who are complaining about this problem.  I am using the import/export wizard into/out of SQL server from excel spreadsheets and getting the same error as everyone else.  Given the severity of the error and the number of people it impacts,  it would be nice for us to get an ETA or update on how Microsoft is going to resolve this error which is disrupting everyone's business activities.
    Thursday, October 12, 2017 6:28 PM
  • When is this going to be fixed? This is related to recent updates made to my machine yesterday (Oct 11) on Windows 8.1 KB4041693 and KB4043763.  This is severely impacting my workflow and the workflows of others who are complaining about this problem.  I am using the import/export wizard into/out of SQL server from excel spreadsheets and getting the same error as everyone else.  Given the severity of the error and the number of people it impacts,  it would be nice for us to get an ETA or update on how Microsoft is going to resolve this error which is disrupting everyone's business activities.

    In the meantime, I have discovered that I can import a spreadsheet into SQL server if the spreadsheet is open on my desktop.  Previously, it had to be closed.  I cannot export data from SQL Server to a spreadsheet though and must export to a tab delimited file.  

    This error is inconveniencing everyone...why doesn't Microsoft test software before it is released?  And why haven't we heard from Microsoft about an ETA for fixing this problem???  Why the silence?

    Thursday, October 12, 2017 6:34 PM
  • The problem is really serious for me. Three productions systems running Windows 10 I manage severely stopped working today! The KB 4041676 has been breaking the data management. 

    Rolling back KB 4041676 helped but now I have to keep system not updated.

    When the FIX will be available?


    Thursday, October 12, 2017 6:42 PM
  • We deal with this problem

    1.uninstall Oct 11 updates
    KB4041676 -- Windows 10 Version 1703
    KB4041691 -- Windows 10 Version 1607 and Windows Server 2016
    KB4041693 -- Windows 8.1 and Windows Server 2012
    KB4041681 -- Windows 7 and Windows Server 2008 R2

    2.change Microsoft.Jet.OLEDB.4.0 to Microsoft.ACE.OLEDB.12.0
    if you only have office 2003 or need create a excel file,must install this
    2007: https://www.microsoft.com/en-us/download/details.aspx?id=23734

    wish all the best

    rick
    Friday, October 13, 2017 1:22 AM
  • The problem comes up with the latest security updates.

    Windows 7 KB4041681
    Windows 8.1 KB40416393
    Wndows 10 KB4040724
    KB4041676

    We facing this issue when we directly try to create an Excel file with ODBC.

    See: https://stackoverflow.com/questions/46706128/odbc-export-to-excel-fails-under-windows-7-windows-8-x-and-windows-10


    Martin Richter -- MVP for VC++ [Germany] -- http://blog.m-ri.de

    Friday, October 13, 2017 5:43 AM
  • I've the same problem on a Windows Server 2008, when I try import from Excel with ODBC (Microsoft.Jet.OLEDB.4.0). Uninstall KB4041681 solve this problem.  Thank you.

    Oldrich

    Friday, October 13, 2017 7:52 AM
  • Hi Will,

    I have the same problem after the October 10 update.

    When use Provider=Microsoft.Jet.OLEDB.4.0 to connect excel file will get Unexpected error from external database driver (1).

    Rick

    Same issue here, after installing October 10, 2017—KB4041676 (OS Build 15063.674).

    Mihai

    • Proposed as answer by Abdaddy100 Thursday, November 02, 2017 1:14 AM
    Friday, October 13, 2017 10:16 AM
  • use the Microsoft.ACE.OLEDB.12.0 driver instead, it worked for us. Would like to know if this is a MS oversight or whether they just aren't supporting Microsoft.Jet.OLEDB.4.0 though. 
    Friday, October 13, 2017 2:48 PM
  • Hello

    Installing the AccessDatabaseEngine and using Miscrosoft.ACE.OLEDB.12.0 provider will work out and if you keep Excel 8.0 in the connexion string, you can still use .xls files.

    After installing the AccessDataBaseEngine Try changing :

    connLine = @"Provider=Microsoft.Jet.OLEDB.4.0;Data Source='" + filename + @"';Extended Properties=""Excel 8.0;HDR=Yes;""" ;
    System.Data.OleDb.OleDbConnection dbConn = new System.Data.OleDb.OleDbConnection(connLine);
    dbConn.Open();

    to

    connLine = @"Provider=Microsoft.ACE.OLEDB.12.0;Data Source='" + filename + @"';Extended Properties=""Excel 8.0;HDR=Yes;""" ;
    System.Data.OleDb.OleDbConnection dbConn = new System.Data.OleDb.OleDbConnection(connLine);
    dbConn.Open();
    Friday, October 13, 2017 3:46 PM
  • Uninstall recent updates

    Why would I need to update my code because someone changed a connection string for a driver.  They should have created a new driver, and new connection string instead of breaking the old one!  If they were going to change it, they should have changed it to "Microsoft Excel Driver" without the file extensions so that this doesn't happen again in the future!

    Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};
    DriverId=790;
    Dbq=[FilePath];
    DefaultDir=[FolderPath]

    Uninstall and Reboot

    https://www.ghacks.net/2017/10/10/microsoft-security-updates-october-2017-release/

    Windows 7 SP1 and Windows Server 2008 R2 SP

    • KB4041681-- 2017-10 Security Monthly Quality Rollup for Windows 7 for x86-based Systems
    • KB4041678 -- 2017-10 Security Only Quality Update for Windows Embedded Standard 7 for x64-based Systems

    Windows 8.1 and Windows Server 2012 R2

    • KB4041693 -- 2017-10 Security Monthly Quality Rollup for Windows 8.1 for x86-based Systems
    • KB4041687 -- 2017-10 Security Only Quality Update for Windows 8.1 for x86-based Systems

    Windows 10 and Windows Server 2016 (version 1607)

    • KB4041691-- 2017-10  Cumulative Update for Windows 10 Version 1607 and Windows Server 2016

    Windows 10 and Windows Server 2016 (version 1703)

    • KB4041676 -- 2017-10 Cumulative Update for Windows 10 Version 1703

    Regards,


    Tray

    Friday, October 13, 2017 7:09 PM
  • Had a similar problem with this update causing ODBC not to work when merging from excel2003 spreadsheet to WORD 2003 document.

    Uninstalled KB4941676 and everything worked fine.

    Unfortunately the update reinstalls quite soon after.

    Need some method tp prevent update reinstalling

    Whito

    Monday, October 16, 2017 3:50 PM
  • Had a similar problem with this update causing ODBC not to work when merging from excel2003 spreadsheet to WORD 2003 document.

    Uninstalled KB4941676 and everything worked fine.

    Unfortunately the update reinstalls quite soon after.

    Need some method tp prevent update reinstalling

    Whito

    Monday, October 16, 2017 3:51 PM
  • Had a similar problem with this update causing ODBC not to work when merging from excel2003 spreadsheet to WORD 2003 document.

    Uninstalled KB4941676 and everything worked fine.

    Unfortunately the update reinstalls quite soon after.

    Need some method tp prevent update reinstalling

    Whito

    Monday, October 16, 2017 3:53 PM
  • Deleted
    • Edited by Chrone Meade Wednesday, October 18, 2017 4:48 PM
    Monday, October 16, 2017 4:00 PM
  • I had the same issue. Although changing the JET driver for the ACE driver did work. I would not recomend it for server-side solutions. If you read the information given at the moment of download of the office component, you will encounter that the ACE driver is not recomended for server-side solutions.


    Monday, October 16, 2017 8:26 PM
  • We have been unable to upload to our website using our interface and the host server has informed us this is the reason why. This ability is crucial to our business and hope for a new released update correcting what has been broken with this update..
    Monday, October 16, 2017 10:22 PM
    • Proposed as answer by Chrone Meade Tuesday, October 17, 2017 2:46 PM
    • Edited by Chrone Meade Wednesday, October 18, 2017 4:47 PM
    • Unproposed as answer by Chrone Meade Wednesday, October 18, 2017 4:47 PM
    Monday, October 16, 2017 11:13 PM
  • We had another customer that just reported they uninstalled KB4042895 to work around this issue. 

    I researched and determined that this was yet another October 10th update that included a Microsoft JET Database Engine update.

    I have found several solutions and I will share this will all.

    The connection string is specific to Excel Versions.

    The old connection string was used for Office 97/2000/2003.

    The old connection string worked until Microsoft released their recent October Jet Database Engine updates.

    The new connection string wasn't introduced until Office 2007, but many were not using it because the old connection string still worked as expected.

    The updates are replacing the excel odbc driver files.

    The first thing I have always had issues with is that these dll files for Microsoft Office are in the \windows directory and not in the \program files\microsoft office directory.

    32 bit DLL:

    c:\windows\syswow64\msexcl40.dll was replaced.

    64 bit DLL:

    c:\windows\system32\msexcl40.dll was replaced.

    I was able to determine that you can take ownership of this file, and give administrators full access, then replace the file with a known working version.

    Prior to this last round of windows updates, I had msexcl40.dll version 4.00.9756.0 and this version works without an issue.

    I can confirm that I can put the old file back and it works.  The new version is 4.00.8x did not work.

    Finally, I wrote the following vb code for excel which solves these issues for us and may be helpful to others.

       'Office 2003
        If Application.Version = "11.0" Then
            MyConnection.Open "DRIVER={Microsoft Excel Driver (*.xls)};DriverId=790;" & _
            "ReadOnly=True;DBQ=" & MyFile & ";"
        ' DriverId=790: Excel 97/2000
        End If
        
       'Office 2007
        If Application.Version = "12.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If     

        'Note There is no Office Version 13

        'Office 2010
        If Application.Version = "14.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If
        
        'Office 2013
        If Application.Version = "15.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If
     
        'Office 2016
        If Application.Version = "16.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If

        
    Regards,


    Tray


    • Edited by DBS_Tray Wednesday, October 18, 2017 1:11 AM Correction
    Monday, October 16, 2017 11:47 PM
  • Hello,

    thank you for explaining the issue. I´m not sure how serious is this for other people in this thread, but for me this is quite devastating. I work in SW company, we have roughly 500 users who use our old products (4 applications) and they all stopped working . They are mostly compiled using VC6, and they use quite old and obscure libraries(for example DAO). From last wednesday we have 50 calls per day user complaining that our apps do not work. Until now we recommended to uninstall those updates and wait for MS to fix this.

    I have no idea what should we do now...

    Tuesday, October 17, 2017 5:18 AM
  • This is all great stuff. My development group is about to ship a product and I see a bug roll in this morning about having to keep an Excel file OPEN in order to be able to make a successful database connection. No code changes have happened in the related area, so I run unit tests locally and they fail! Our continuous integration system, however, is passing.

    Now it makes sense; the build system didn't receive the update, but the QA tester and my systems have received the update.

    Given that everything continues to work, if the file is open in Excel (seems like an odd situation), this seems like a bug that is should be fixed by Microsoft? Would like to know whether I need to rush in some kind of fix into a product that is shipping imminently, and if I do that, whether the fix itself won't be later broken by a Microsoft fix!


    Wayne H

    Tuesday, October 17, 2017 5:42 AM
    • As mentioned in forums.embarcadero.com/thread.jspa?messageID=902557&tstart=0 and forum.kanors-emr.org/showthread.php?tid=571&pid=2652#pid2652, the last update installs version 4.0.9801.1 of msexcl40.dll.

    1. Find prior version (4.0.9801.0) of msexcl40.dll

    2. Place in another directory. They suggest the application directory, but since in the next step you will modify registry to point to this older version, it can probably go anywhere.

    64-bit Operating System

    3. Update registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Excel\win32 to point to the location from step 2.

    32-bit Operating System

    3. Update registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\win32 to point to the location from step 2.

    32-bit , MS Office 2003

    3. Update registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\win32old to point to the location from step 2.





    • Edited by avoriv Wednesday, October 18, 2017 7:16 AM
    • Proposed as answer by pkarandi Monday, October 23, 2017 8:47 PM
    Tuesday, October 17, 2017 5:49 AM
  • Thank you for sharing this. It works great.

    I have just created setup file that does these steps. If anyone is interested I can post it here.

    Tuesday, October 17, 2017 9:15 AM
  • I found a work around by changing my connection string to the following:

    Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};
    DriverId=790;
    Dbq=[FilePath];
    DefaultDir=[FolderPath];



    John Inology

    As mentioned, while the issue with JET drivers and KB4041693 gets investigated, a workaround is to use the ACE drivers. The easiest way to get them is by installing the Access Database Engine from https://www.microsoft.com/en-in/download/details.aspx?id=13255. The version to install depends on the architecture of the process using the drivers. For most Classic ASP apps, that would be x86.

    Once installed the ACE drivers, the ODBC Data Source Admin console (C:\Windows\SysWOW64\odbcad32.exe) will list the new drivers, including the Excel one. 

    Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)

    Once the driver is installed, the connection string needs to be modified in the application. For Classic ASP, a typical invocation would be

    Dim DbConn, XLSrs
    XLSstrConn="DRIVER={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)}; DBQ=" & Server.MapPath("Test.xls") & ";DefaultDir=" & Server.MapPath(".") &";DriverId=790; FIL=MS Excel; MaxBufferSize=512; PageTimeout=5"
    set rsCount=server.createobject("adodb.recordset")	
    rsCount.activeconnection=XLSstrConn

    For general guidelines and consideration on using Office automation in server applications, please refer to https://support.microsoft.com/en-US/help/257757


    Tuesday, October 17, 2017 10:45 AM
  • >I've the same problem on a Windows Server 2008.
    >But I don't have the KB4041678-681-676 installed.
    >The error was: [Microsoft][Driver ODBC Excel] Reserved error (-5016).
    >Any suggestions ?

    Hi Claudio,

    Same issue here with "driver={Microsoft Excel Driver (*.xls)}" on Windows Server 2008

    I removed all Microsoft Update of october 12, 2017 : ok
    but it's a workarond 

    Regards
    Francis

    Tuesday, October 17, 2017 11:46 AM
  • I have a test suite for a product component that tests a variety of data sources and connections, including Excel, Access, Oracle, dBase, text, SQL Server and others, in both 32-bit and 64-bit. A number of these tests started to fail after the KB update.

    I note the recommended work around above, and after updating tests to use this driver instead, many tests pass again, but not all.

    A handful of tests still fail, but with a different error.

    "Could not find installable ISAM."

    This error appears to be associated with *very* old Excel file formats, so maybe it's not a practical problem, but just thought I would highlight that the work around is not providing identical behavior to the original.

    It would be nice to know whether support for older file formats is being dropped, or where to find out that kind of information, since it's not a good look for unit tests to start failing over-night in a component of a product that was supposed to ship last week!

    For ODBC this turns out to be OK (other than the error noted above) since our software exposes the connection string to users, however, for OLEDB we provide some wrappered connections for Access and Excel to make it easy for users who have no clue about connection strings. So the problem for me is, do I change the code to use ACE behind the scenes, at the 11th hour, and does that break things for people without the KB? Will it break again if there is a hot fix for the KB or updated KB? Or, do I just leave the code as it was working fine for many years, and recommend users to un-install KBs until the problem is solved?


    Wayne H

    Tuesday, October 17, 2017 12:21 PM
  • Hi albigi.

    Thanks for your recommendation.

    Problem is, that recommended AccessDatabaseEngine.exe (32 bit) can not be installed when 64 bit Microsoft Office is installed. 

    What can I do, please ?

    Pavel

    Tuesday, October 17, 2017 1:32 PM
  • Hi,

    I'm having similar issue on my company... when we try to do an export with an application we got error saying

    The workaround for this it's uninstall the KB or replace the msexcl40.dll by an older version...

    Microsoft, can you please provide permanent fix for this?

    Regards,

    Nuno


    -

    Tuesday, October 17, 2017 2:40 PM
  • I would like to report back the following information.

    After pushing thousands of updates to many different customers running many different versions of Microsoft Office 2003, 2007, 2010, 2013, and 2016, we finally see light at the end of the tunnel.

    We successfully implemented the new code below that appears to working as required.

    A minor tweak to correct version 12 for Office 2007 was made after initial deployment, but overall things are much better.

    The code is specifically designed to use the documented connection strings available to the different identified product versions of Microsoft Excel based on how they were originally designed to work.

    This is based on following the technical documents provided by Microsoft and is also based on them not currently being updated or altered. That was my disclaimer.

    The reason we choose this method was strictly because it was simply not practical to uninstall thousands of updates, and it was not practical to install thousands of new new drivers.  Customers lack permissions, technical knowledge, etc..

    While uninstalling the bad updates provides a temporary means to get a customer back up and running, it is definitely not a long term fix.  Microsoft will likely release future driver updates that will simply trigger the same issues.  So we found it easier to conform.

    So to comply with the documented methods, we choose to go with the below.

    If Microsoft somehow updates the excel driver to no longer work using the following methods, it will break a majority of their end users who followed their documentation and are also utilizing this same method.

       'Office 2003
        If Application.Version = "11.0" Then
            MyConnection.Open "DRIVER={Microsoft Excel Driver (*.xls)};DriverId=790;" & _
            "ReadOnly=True;DBQ=" & MyFile & ";"
        ' DriverId=790: Excel 97/2000
        End If
        
       'Office 2007
        If Application.Version = "12.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If     

        'Note There is apparently either no Office Version 13, or we just don't have any.

        'Office 2010
        If Application.Version = "14.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If
        
        'Office 2013
        If Application.Version = "15.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If
     
        'Office 2016
        If Application.Version = "16.0" Then
        MyConnection.Open "Driver={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)};DBQ=" & MyFile & ";"
        End If

    For anyone who is interested, the msexcl40.dll version 4.0.9702.0 file is in the following hot fix:

    https://support.microsoft.com/en-us/help/943509/description-of-the-jet-4-0-database-engine-hotfix-package-for-windows

    This may be the last time I post here, but I may check back again.

    May the force be with you!

    Wednesday, October 18, 2017 1:44 AM
  • ** Official Update **

    We have created a statement on this issue in the following link:

    https://blogs.msdn.microsoft.com/dataaccesstechnologies/2017/10/18/unexpected-error-from-external-database-driver-1-microsoft-jet-database-engine-after-applying-october-security-updates/

    As a further update, the Office product team has agreed to look into this to work towards a solution.  That said, please still note that the JET provider has been deprecated for 15 years, and we still recommend switching to the ACE provider or the SSIS Excel connector. 

    Thank you all again for providing the workaround you have found and shared with the rest of the community.

    I will be deleting my earlier comments to help avoid confusion.

    ~Chrone with Microsoft SQL Support~

    (Not a forum moderator)

    • Proposed as answer by Chrone Meade Wednesday, October 18, 2017 4:47 PM
    Wednesday, October 18, 2017 4:47 PM
  • Hi Chrone,

    thank you for your information.

    There is the problem with 32 or 64 bit version od Microsoft Office on users computers.

    When a 32 bit Office version is installed, only 32 bit version of Microsoft Access Database Engine 2016 Redistributable I can install. Then do not work our 64 bit application (or our 64 bit DLLs for CAD applications) trying to use MSDE.

    When a 64 bit Office version is installed, only 64 bit version of Microsoft Access Database Engine 2016 Redistributable I can install. Then do not work our 32 bit application trying to use MSDE.

    We need use both 32 and 64 bit applications at the same time.

    Could you give me an advice, how to do it, please ?

    Best regards,

    Pavel



    Thursday, October 19, 2017 12:50 PM
  • While I thank Microsoft for getting involved, I am concerned with their comments.

    ------------------------------------------------------------------------------------------------------------------------------

    #1 Microsoft Jet Database Engine 4.0: Starting with version 2.6, MDAC no longer contains Jet components. In other words, MDAC 2.6, 2.7, 2.8, and all future MDAC/WDAC releases do not contain Microsoft Jet, the Microsoft Jet OLE DB Provider, the ODBC Desktop Database Drivers, or Jet Data Access Objects (DAO). The Microsoft Jet Database Engine 4.0 components entered a state of functional deprecation and sustained engineering, and have not received feature level enhancements since becoming a part of Microsoft Windows in Windows 2000.

    #2 When looking into this issue, the largest thing to note is: The JET provider has been deprecated as of 2002. The last changes were made to this in 2000. See the following article for more details.

    Data Access Technologies Road Map

    https://msdn.microsoft.com/en-us/library/ms810810.aspx

    #3  This patch seems to update Excel Jet connector from V4.00.9801.0 to v4.00.9801.1.

    One of the workarounds is to uninstall the KB and it may fix the issue. Although, in some instances it may not help to resolve the issue.

    #4  So, in short the JET provider has been working for a good 15 years after deprecation, but this most recent update caused a change which requires an update to how you are connecting to the Excel file. For the SSIS packages, we recommend pointing to the Excel by our Excel connector instead of using OLEDB.

    #5  In all current known cases, using the ACE provider works to connect to the excel files in lieu of the JET provider. The following download is the most up to date version for the ACE provider:

    Microsoft Access Database Engine 2016 Redistributable

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

    #6  The best recommended solution is to move to Microsoft ACE OLE DB provider.

    Apart from this, Microsoft is working on a resolution and will provide an update in an upcoming release of the security patch. This is expected to be available in another 2-3 weeks or earlier.

    If you are still encountering any related issues, please reach out to the Microsoft CSS team.

    ------------------------------------------------------------------------------------------------------------------------------

    First, if the driver was depreciated and not supported since 2000, then no one should be working on security updates that replace this file.  If it worked for 15 years after depreciation that tells you something that Microsoft apparently does not understand.  If the version number changed, then obviously someone has changed it.

    Second, the suggestion that everyone should rewrite and supply thousands of previously working customers with a new ACE drivers and code for something that was working prior to a Windows Security Update is not practical. 

    Third, the excel driver should not have been touched if it is abandoned.

    Thank you for those who pointed out that you can't even transfer your excel document to a word doc now.  For something that is supposed to be depreciated, it shows that it is still very much in use by Microsoft themselves.

    If you want to keep your Microsoft Customers, you can't just go around abandoning things that work.  The number one reason Microsoft continues to loose developers is because after starting a project it is simply abandoned and leaves your developers to hang.  When it works for 15 years, why would you be surprised that it is still in use!  It is also not acceptable to break it and then try to abandon it because you don't want people to use it anymore.

    I like others are now considering rewriting all new code to no longer use Microsoft Office Automation in order to avoid any future issues with Windows Updates and Microsoft abandoning support for their products.

    By the way, installing the new Microsoft Access Components or Runtime breaks any previously working version of Access.  They simply can't co exist.

    If this is the direction we all choose to go then Microsoft will simply loose sales for Microsoft Office simply because the only thing preventing a customer from using some other open source suite is that it currently doesn't match up to all the features that Microsoft Office has.  If you abandon those features you are abandoning your customers.

    Regards,

    Tray

    Thursday, October 19, 2017 3:24 PM
  • First, if the driver was depreciated and not supported since 2000, then no one should be working on security updates that replace this file.  If it worked for 15 years after depreciation that tells you something that Microsoft apparently does not understand.  If the version number changed, then obviously someone has changed it.

    I will need to disagree with this. Obviously, if a security vulnerability is detected, it does not matter that the module is deprecated and not touched for 15 years. The vulnerability still needs to be addressed.

    But obviously, it could have been performed in a cleaner way.

    Thank you for those who pointed out that you can't even transfer your excel document to a word doc now.  For something that is supposed to be depreciated, it shows that it is still very much in use by Microsoft themselves.

    Microsoft's record when it comes to use of deprecated features is not very good. Within the SQL Server product there are plentiful of examples.

    Thursday, October 19, 2017 9:05 PM
  • I had the same problem using Excel ODBC driver, and then my network driver quit with error "Windows could not load the driver."  Without access to the Internet, I could not see this helpful stream, but I did think there was something corrupt in the system that a rollback might fix. I attempted to rollback to the previous system configuration, which happened to be prior to the October 10 updates you all are talking about.  Bad news is that system restore quit with an error code and said it hadn't restored files.  Good news is that apparently it did do something, because both drivers now work.  I'm not sure which of the three updates installed that date was the culprit. There was as security update KB4041681 and a .net KB4043766.  Anyone know definitively which one it was?
    Friday, October 20, 2017 2:09 AM
  • I'm having the exact same issue. Excel was working fine when I test ran mail merge for name tag labels I created in Greeting Card Factory Deluxe Version 9 last week on October 10.  While trying mail merge again yesterday, it will not work and I received the same ERROR messages as John at Inology.  This doesn't make sense. Greeting Card Factory Deluxe was installed in August 2016.  Mail merge worked via Excel 1997-2003 worksheet up until a few days ago. Please help me get it working again. I have a large label project that must be done!

    I see that you found a "work around" by changing your connection string. I don't have a clue how to do that. - Cardcrafter

    Friday, October 20, 2017 3:35 AM
  • Hey Neil,

    Just wanted to say thanks. This solution worked to fix the issue we were experiencing after applying KB4041681. Very grateful for your help.

    -Ben

    Friday, October 20, 2017 4:57 PM
  • Installing Microsoft.ACE.OLEDB.16.0 worked for me on my local machine as explained here.

    But the webhoster is using Microsoft Jet Database Engine 4.0.

    So, as a workaround, I converted the XLS file to CSV files (one CSV file per sheet).

    Web.config

    <configuration>
      <connectionStrings>
        <add
          name="myConnectionString"
          connectionString="Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\myPathToCSVFiles\; Extended Properties='Text;HDR=Yes;FMT=Delimited'"
        />
    


    Code-behind (C#)

    string connection_string = ConfigurationManager.ConnectionStrings["myConnectionString"].ConnectionString;
    string sheet_filename = "sheet1.csv";
    using (OleDbConnection connection = new OleDbConnection(connection_string))
    {
        OleDbCommand command = new OleDbCommand();
        command.Connection = connection;
        connection.Open();  // OK with path to CSV files. Throws an exception with XLS files.
        command.CommandText = String.Format("SELECT * FROM [{0}]", sheet_filename);
    


    Saturday, October 21, 2017 5:12 AM
  • Sorry, newbie pulling hair out.

    Did the MS Access install but my connection string does not have the same reference as is shown in the documentation.

    This is what mine looks like in the connection property window in Excel 

    DBQ=C:\BDR\33activity.xls;DefaultDir=C:\BDR;Driver={Driver do Microsoft Excel(*.xls)};DriverId=790;FIL=excel 8.0;MaxBufferSize=2048;MaxScanRows=8;PageTimeout=5;ReadOnly=1;SafeTransactions=0;Threads=3;UserCommitSync=Yes;

    Using win 10 and Excel 2013

    Linking to an XLS file.

    Connection type is a database query

    Enterprise laptop so a lot is locked down

    Sorry guys, just new at this and pulling my hair out..... and sorry for the cross post to another group, just don't know where to look.

    Thanks for any help

    Saturday, October 21, 2017 11:14 AM
  • Changing the connection string work on us.

    Thanks!

    Sunday, October 22, 2017 9:27 AM
  • Download wushowhide.diagcab and you will be able to hide KB4941676 and prevent it from downloading/installing again. Very usefull tool:

    https://support.microsoft.com/nl-nl/help/3073930/how-to-temporarily-prevent-a-driver-update-from-reinstalling-in-window

    Sunday, October 22, 2017 5:16 PM
  • Please point us to the documentation of what vulnerability was discovered and supposedly updated in msexcel40.dll driver.
    Monday, October 23, 2017 1:27 PM
  • Uninstalling Updates did not help our situation.

    Installing Microsoft Access Database Engine 2016 did help, however. We installed the 32 bit version on our SQL 2008 R2 Server and now the import wizard can use excel files again, thanks to the new drivers supplied in the latest Access Database Engine

    Monday, October 23, 2017 5:55 PM
  • This was a great solution for me, saving me a ton of time!  Thanks for sharing this!
    Tuesday, October 24, 2017 2:54 PM
    • As mentioned in forums.embarcadero.com/thread.jspa?messageID=902557&tstart=0 and forum.kanors-emr.org/showthread.php?tid=571&pid=2652#pid2652, the last update installs version 4.0.9801.1 of msexcl40.dll.

    1. Find prior version (4.0.9801.0) of msexcl40.dll

    2. Place in another directory. They suggest the application directory, but since in the next step you will modify registry to point to this older version, it can probably go anywhere.

    64-bit Operating System

    3. Update registry key HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\Excel\win32 to point to the location from step 2.

    32-bit Operating System

    3. Update registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\win32 to point to the location from step 2.

    32-bit , MS Office 2003

    3. Update registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\Excel\win32old to point to the location from step 2.





    Thanks avoriv.  Your post did the trick for me.  Before step 1, I just did a search on the C: drive for the msexcl40.dll file.  There were 4 different copies on my machine, so I grabbed the oldest one which was last modified on 7/31/2017 and was 332 KB in size.  I copied this file to a new directory (so your comment in step 2 about putting the file anywhere was correct I think), then performed step 3 since I have a 64 bit machine, and voila!  My Excel connectors in my SSIS packages are now working!  Thanks again.
    Thursday, October 26, 2017 3:23 PM
  • After installing Microsoft Access Database Engine 2016 Redistributable I cannot import Access 97 format file using the Access Driver (ACEODBC.DLL version 16.00.4513.1000)
     I use ODBC:
     My connection string is:
     DRIVER=Microsoft Access Driver (*.mdb, *.accdb);
    MaxBufferSize=2048;
    FIL=MS Access;
    DriverId=281;
    DefaultDir=C:\hash;
    DBQ=C:\hash\book.mdb;
    Friday, October 27, 2017 10:11 AM
  • Sorry men.

    I have only Excel 2003 on my PC.

    So I can't download Microsoft Access Database Engine 2016 or similar because they need that I unistall Microsoft Office 2003.

    How can I resolve this problem?

    I tried to use:

    Str = "DRIVER={Microsoft Excel Driver (*.xls)}; DBQ=" & d Server.MapPath("File.xls")

    Str = "DRIVER={Microsoft Excel Driver (*.xls, *.xlsx, *.xlsm, *.xlsb)}; DriverId=790; DBQ=" & Server.MapPath("File.xls") 

    Str = "Provider=Microsoft.Jet.OLEDB.4.0; Data Source=" & Server.MapPath("File.xls") & ";Extended Properties=""Excel 8.0;HDR=Yes;IMEX=1;"""

    Str = "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" & Server.MapPath("File.xls") & "; Extended Properties=""Excel 12.0; HDR=No;"" "

    Is there a solution without unistall updates or make change on REGISTRY KEY?

    Monday, October 30, 2017 11:24 AM
  • thank you for posting this -- it fixes the problem on my 64bit windows 10 pc.
    Wednesday, November 01, 2017 12:04 AM
  • We are using Excel imports to bring data into Dynamics AX. This update caused that function to break. We have removed the offending update from our local users and from our Citrix System (specifically the App servers). The issue is that does not fix the Citrix users, which is most of our user base. The local users have been fixed by removing the KB that caused the issue. Does anyone have any other recommendations?
    Wednesday, November 01, 2017 1:32 PM
  • Your table should include 2 additional updates:

    KB4041676 -- Windows 10 Version 1703
    KB4041691 -- Windows 10 Version 1607 and Windows Server 2016
    KB4041693 & KB4041687 -- Windows 8.1 and Windows Server 2012
    KB4041681 & KB4041678 -- Windows 7 and Windows Server 2008 R2

    There is no Windows 10 equivalent for these updates.

    This also fixed my Citrix Issue mentioned before in this forum.

    Thanks for the information that got us to this fix.

    Wednesday, November 01, 2017 7:04 PM
  • This issue appears to affect dataset's created in Visual Studio that connect to Microsoft Access database files that are constructed in the following fashion:

    1. The MS Access database to which the dataset is connected contains linked tables to another MS Access database where the tables have defined table relationships.  Sporadically, some of the tables within the dataset are no longer accessible, nor are they available to be accessed from the dataset.  Furthermore, the connections throw the "Unexpected error from external database driver (1)" error when the application runs in both the debugger and when deployed.

    Uninstalling the KB4041676 update on the development machine does solve the problem within Visual Studio and the debugger.  I have not yet tested on a deployment computer.

    Not sure if this is the correct place to post this comment.  Hope the moderator will repost appropriately.

    Thursday, November 02, 2017 8:12 PM
  • It worked for me as well. 

    Just replaced the Jet driver with ACE.


    - Vicky

    Friday, November 03, 2017 4:25 AM
  • Hi all,

    do you know the impact of uninstall that KB ?

    Thank you


    Regards, Biiboy


    • Edited by biiboy Tuesday, November 14, 2017 4:44 AM
    Tuesday, November 14, 2017 4:44 AM
  • Does anyone know if the November updates will cause the same thing?

    If not (and IF MS fixed the issue), will they correct the issue on those systems with the October updates already installed?

    Tuesday, November 14, 2017 3:54 PM
  • November updates also causing the same issue, Uninstall Patches Not recommendable

    Look below topic, it may be help to fix the issue

    Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine error, and discussed the fact that most problems are caused by the incorrect bit-ness of the selected component

    IIS Express

    IIS Express 7.5 only comes as a 32-bit application. Therefore the 64-bit version of ACE will not work with it. iis8 or greater offer both 32-bit and 64-bit options, so you can download that instead. There is no option to enable 32-bit applications in current versions of IIS Express. However, by default, Visual Studio uses the 32-bit version. You can change this from within Visual Studio by going to Tools » Options » Projects And Solutions » Web Projects » General,

    and choosing the tick box (use the 64 bit version of IIS version of the website and project) and then finish it

    if you launch IIS Express from the command line instead, navigate to the correct folder instead. The 32-bit version is installed by default in C:\Program Files (x86)\IIS Express. The 64-bit version is installed in C:\Program Files\IIS Express. You can determine which version of IIS Express is running from the Processes tab in Task Manager:

    • Proposed as answer by fedex910302 Thursday, November 16, 2017 7:58 PM
    Wednesday, November 15, 2017 9:54 AM
  • You can use this:

    Microsoft.ACE.OLEDB.12.0.

    but someone knows when is this corrected?.

    Thursday, November 16, 2017 8:02 PM