UPDATE: As informed, the security patches with the fix was rolled-out yesterday 11/14. We would request you to test this and verify that the issue is addressed. If not, please let us know. Please find the information below, Windows 2008 Windows 7/2008 R2 -Monthly Roll-up - -Security-only update - Windows 2012 -Monthly Roll-up - -Security-only update - Windows 8.1 and 2012 R2 -Monthly Roll-up - -Security-only update - Windows 10 Fall (“November”) Update, version 1511 - Windows 10 Anniversary Update, version 1607, and Server 2016 - Windows 10, version 1703 - We have been seeing a recent influx in cases where the JET provider is no longer able to connect after the October update. This update (released October 10 th, 2017) includes a security update release that inadvertently affects the JET provider. The update was kb4041678 and included in the patch kb4041681.

These patches affected the Operating System, which adversely has an issue with the following technologies: Microsoft Windows Search Component, Windows kernel-mode drivers, Microsoft Graphics Component, Internet Explorer, Windows kernel, Windows Wireless Networking, Microsoft JET Database Engine, and the Windows SMB Server. It is important to note that the changes were not to these technologies themselves. Types of errors witnessed: Unexpected error from external database driver (1). (Microsoft JET Database Engine) MicrosoftDriver ODBC Excel Reserved error (-5016). MicrosoftODBC Excel DriverGeneral Warning Unable to open registry key 'Temporary (volatile) Jet DSN for process WORKAROUNDS & SOLUTION: Approach 1: Use Microsoft.ACE.OLEDB.12.0 or Microsoft.ACE.OLEDB.16.0: (Recommended) The following updates where not intended to cause any issue with Microsoft Jet Database Engine 4.0, at the same time the product group developers were not verifying these updates would be compatible with Microsoft Jet Database Engine 4.0 data provider as it had been deprecated back in 2002: As both articles suggest for the below workaround. 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 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 Excerpt: “ 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.” 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.

You can locate the Excel Connector by opening up an SSIS package within SQL Server Data Tools. Create or go to an existing Data Flow task. You can see the Excel Source in the “Other Sources” Section: When using JET, this is done through an OLEDB/ODBC source. You can use the same method for the ACE provider. The ACE provider will work, however it is not supported for use with programs such as SSIS, Management Studio, or other applications.

Although this doesn’t tend to cause issues, it is important to note. That notwithstanding, the ACE drives provides the same functionality as the JET provider did. The only limitation I am aware of is the same you were encountering with JET which is that you can't have multiple users connecting to and modifying the Excel file. Microsoft Access Database Engine 2016 Redistributable Excerpt: The Access Database Engine 2016 Redistributable is not intended: 4. To be used by a system service or server-side program where the code will run under a system account, or will deal with multiple users identities concurrently, or is highly reentrant and expects stateless behavior. Examples would include a program that is run from task scheduler when no user is logged in, or a program called from server-side web application such as ASP.NET, or a distributed component running under COM+ services. I understand that there are many users that don’t know how many packages might be experiencing this issue.

It is possible to look through your dtsx packages using the following method. If you run a command prompt as an administrator, you can use the find command to look through the packages for the keyword JET.

This will state all the files it looks through, but you will see a connection manager result for the files that have this in them. If you have already updated the package from JET to ACE, then this will not show the connection manager and is not affected by this security update.

This really sucks! For right now I am just going to use an old machine, I have a 2003 Access routine that imports a series of Excel files from Investors Business Daily with stock information on them called etables.

The excel files are in a very early version of Excel. I tried to upgrade to a later version of access but the routine would stop on each excel file and I could not figure out how to rewrite the code to make the operation automatic. I like the idea of changing the registry key to point to a different location best, but can’t figure out how to get the right jet file. Hi, I came across the same issue, but when I try the approach 1 by installing the Access Database Engine 64 bit version I get below error “You cannot install the 64 bit version of Microsoft Access Database Engine because you have 32 bit Office Products installed ” and when I try to install the 32 bit version I get the error “You cannot install the 32 bit version of Microsoft Access Database Engine because you have 64 bit Office Products installed ”.

What kind of error messages are being shown? They are opposite to each other irrespective of the version installed it just throws an error. Hi Adeel, Request you to read the blog completely. We had mentioned about this clearly with a solution to the same problem that you had discussed. “But there is an option where you can have both the versions installed on the same machine by performing a “/quiet” install of these components from command line.

To do so, download the desired AccessDatabaseEngine.exe or AccessDatabaeEnginex64.exe to your PC, open an administrative command prompt, and provide the installation path and switch /quiet. Ex: C: Files AccessDatabaseEngine.exe /quiet. This approach is documented in Microsoft Access Database Engine 2016 Redistributable download page under the Additional Information section.”. Very disappointing reading this “So, in short the JET provider has been working for a good 15 years after deprecation” So the best you guys can do is wreck it? ‘m been using Access for 23 years, yes 23! And found it a wonderful product, all thru many versions of Windows.

I have databases running for 20 years and now you guys say “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.” You should know this has a lot of consequences in the real world of real business apps. The NUMBER ONE selling point of apps built with Access is that it is extremely stable which means in computer terms that apps can be deployed without managing every update or constantly upgrading to new versions. What do I say to customers that have been using my apps for 10 years or more? I just spent a couple of hours trying Approach 1 and still no export!

Db Error Codes

2010,2016 Redistributable and no go. Approach 2 does work in my testing. When is the fix coming? 1)after selecting the.xls file, if i click on NEXT BUTTON, I’m getting this Exception “Unexpected error from external database driver (1).” 2)If Extension is.xlsx I’m Using @”Provider=Microsoft.ACE.OLEDB.12.0;Data Source= ” + path + “;Extended Properties= ”Excel 12.0;HDR=YES;IMEX=1; ””; If Extension is other than.xlsx(.xls) I’m Using @”Provider=Microsoft.Jet.OLEDB.4.0;Data Source= ” + path + “;Extended Properties= ”Excel 8.0;HDR=YES;IMEX=1; ””; Can U pls help me something.It is Very Urgent for me.

I have a legacy third party application that is encountering this issue. However, we do not have access to the source code of this application and we need to correct this as soon as possible to send reports to our client. Is there a work around that does not involve updating the affected application? Has it been confirmed that Microsoft will release a fix to this error without the end users updating legacy applications? Additionally, security updates are managed by our parent company and we do not have the proper administrative rights to uninstall the update or delay its installation.

Any help or information would be greatly appreciated. Hi Krishnakumar, Thanks for the workaround. This was helpful in solving the issue temporarily. But this is critical issue for us as we are using JET engine in our windows desktop application which is widely installed and used by users. Changing the connection, generating the new installer file,rolling out the new version and asking the users to uninstall the previous versions is risky and causes huge customer impact.

Could you please update the details when the fix for this security patch will be available if you are aware of it. POC to contact Microsoft CSS team. Details of Incident or VSO Work item being created for this issue if any?

It’s and things don’t look to be fixed yet. We rebooted our data warehouse servers over the weekend and the patches broke the legacy Jet engine. We’re running SQL 2012 on Windows 2008 R2. We uninstalled the following patches to resolve the issue–with reboots after each uninstall just to be safe. Keep in mind SQL version and O/S version is part of the equation: wusa /uninstall /kb:4040977 wusa /uninstall /kb:4041681 wusa /uninstall /kb:4041678 Note: We noticed that.Net patches were actually stuck and stacked behind.Net patches having the date –on our systems anyway. Once we uninstalled 4040977, the newer.Net patches came flooding through on reboot.

Very bizarre. This identical behavior happened on two separate servers–so this wasn’t just a random anomaly.

In my case, I am working on a client-side application. I have to assume that users could have Office installed as either 32-bit or 64-bit. Additionally, my application is 64-bit, but I have to assume that users could have 32-bit applications using the 32-bit version of Access Database Engine.

So, I am testing the install of both the 32-bit and 64-bit versions of Access Database Engine on the same machine. I am using the “/quiet” switch, and the installations are successful. However, only the last installed Access Database Engine really works. In my case, I installed the 32-bit version first and 64-bit version last. So, if I build my C# test.exe for x64, it works well. But if I build it for x86, then in the call to OleDbConnection.Open, I get an exception: An unhandled exception of type ‘System.Runtime.InteropServices.SEHException’ occurred in System.Data.dll. The results flip if I install the 32-bit version of Access Database Engine last.

Nov 19, 2011 - A variable created by SETX won't be usable until you restart the command prompt. Neatly, however, you can SETX a variable that has already been SET, even if. New user command line won't input download.

Db Error Connect Failed

In that case, my x86 test.exe is successful, but the x64 test gets the exception. Any advice to solve the SEHException? Although mentioned in this article as an option, is installing both using “/quiet” actually supported?

Installing both the 32bit & 64bit Access Database Engine is not supported. It was mentioned in the article just as a workaround if you cannot have 2 different servers for 32bit & 64bit Office processing. Also your requirement doesn’t seem to be realistic, running your test.exe on both the 64bit & 32bit on a same machine. We understand that your clients may have either of Office suite installed (x86 or x64), so you may need to just target your test.exe for one bitness and for clients who aren’t having the same bitness of provider installed, they need install the same using the switch.

Ok, so installing both using “/quiet” is mentioned as a workaround, but not actually supported by Microsoft, and from my testing, does not actually work. So should you edit the article to remove mention of this as a workaround and say that you may only have one installed on the machine and may do so using the “/quiet” switch?

Also, my understanding then is that if my application will require the x64 provider, then from Microsoft’s standpoint any application that requires the x86 provider must run on a different machine. That is the only supported configuration, correct? The Extended Support End Date of Microsoft Access 97 Standard Edition is Not Applicable. The Extended Support End Date of Microsoft Access 2007 is Not Applicable.

Driver Error: Db Is Not Running Shoes

The Extended Support End Date of Microsoft Office Excel 2007 is Not Applicable. The Extended Support End Date of Microsoft Office Excel 2003 is 4/8/2014. Microsoft JET Database Engine is deprecated. Microsoft fixed bug causes applications based on the Microsoft JET Database Engine (Microsoft Access 2007 and older or non-Microsoft applications) to fail when creating or opening Microsoft Excel.xls files, but cannot fix bug causes applications based on the Microsoft ACE Database Engine 2013/2016 to fail when opening Microsoft Access 97.mdb files (that works with ACE 2007/2010). This is one of the solution found after through investigation Solutions to “Unexpected error from external database driver (1)” Steps: First search for Installed Updates ” windows-7-update-kb4041681″ in control panel.

Uninstall this update from your OS Find previous version of msexcl40.dll.(The previous msexcl40.dll can be identified by date of creation).you can search under c: windows Create a directory lets say C: xyz and copy the previous msexcl40.dll to this directory. It suggested to be the application directory, but since in the next step you will modify registry to point to this older version, it can probably go anywhere.So here it does not matter type of directory. Update registry key HKEYLOCALMACHINE SOFTWARE Wow6432Node Microsoft Jet 4.0 Engines Excel win32 to point to the location from step 2. I.e C: xyz msexcl40.dll.

I was getting error Unexpected error from external database driver (1) when I was using below connection string “Provider=Microsoft.Jet.OLEDB.4.0;Data Source=” + MyPath + “;Extended Properties=’text;HDR=Yes;FMT=Delimited'”; After changing below connection string some time its working fine some time getting error ( Invalid argument), Please help. New connection string string ConnectionString = @”Provider=Microsoft.ACE.OLEDB.12.0;Data Source=” + MyPath + “;Extended Properties= ”Excel 12.0; ””; Full error after changing connection string: Message Invalid argument.

Method Name: GetDataFExcel Type: System.Data.OleDb.OleDbException Namespace: System.Data.OleDb. Hi, Can the fix to this problem(KB4048958,KB4048961) cause problems with SSIS packages staying in “Pending Execution” status?

Our SQL server 2012 & 2016 are both currently having this issue after installing november monthly rollup. The following error is shown: A.NET Framework error occurred during execution of user-defined routine or aggregate “validateprojectinternal”: System.ComponentModel.Win32Exception: A required privilege is not held by the client System.ComponentModel.Win32Exception: at Microsoft.SqlServer.IntegrationServices.Server.ISServerProcess.StartProcess(Boolean bSuspendThread) at Microsoft.SqlServer.IntegrationServices.Server.ServerApi.ValidateProjectInternal(SqlInt64 projectId, SqlInt64 versionId, SqlInt64 validationId, SqlString targetEnvironment, SqlInt16 use32BitRuntime).

(Microsoft SQL Server, Error: 6522) Indicating that a required privilege is not held by the client while the service account has all the access. This problem happens both when deploying packages and trying to execute them.