Result StackTrace:
en System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)
en System.Data.OleDb.OleDbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningObject)
en System.Data.ProviderBase.DbConnectionFactory.CreateConnection(DbConnectionOptions options, DbConnectionPoolKey poolKey, Object poolGroupProviderInfo, DbConnectionPool pool, DbConnection owningConnection, DbConnectionOptions userOptions)
en System.Data.ProviderBase.DbConnectionFactory.CreateNonPooledConnection(DbConnection owningConnection, DbConnectionPoolGroup poolGroup, DbConnectionOptions userOptions)
en System.Data.ProviderBase.DbConnectionFactory.TryGetConnection(DbConnection owningConnection, TaskCompletionSource`1 retry, DbConnectionOptions userOptions, DbConnectionInternal oldConnection, DbConnectionInternal& connection)
en System.Data.ProviderBase.DbConnectionInternal.TryOpenConnectionInternal(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
en System.Data.ProviderBase.DbConnectionClosed.TryOpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory, TaskCompletionSource`1 retry, DbConnectionOptions userOptions)
en System.Data.ProviderBase.DbConnectionInternal.OpenConnection(DbConnection outerConnection, DbConnectionFactory connectionFactory)
en System.Data.OleDb.OleDbConnection.Open()
en LinqToExcel.Query.ExcelUtilities.GetColumnNames(ExcelQueryArgs args)
en LinqToExcel.Query.ExcelUtilities.GetColumnNames(String worksheetName, String fileName)
en LinqToExcel.ExcelQueryFactory.GetColumnNames(String worksheetName)
en Infraestructura.Test.Readers.LecturaArchivoExcelTest.PruebaDeErrorEnUso() en K:\NETEnvironment\TransoftWEBSources\src\Infraestructura.Test\Readers\LecturaArchivoExcelTest.cs:línea 40
Result Message:
Test method Infraestructura.Test.Readers.LecturaArchivoExcelTest.PruebaDeErrorEnUso threw exception:
System.Data.OleDb.OleDbException: Error no esperado desde el controlador de la base de datos externa (1) .
Regards,
César
my educated guess is, that KB4041678 and/or KB 4041681 is responsible for this. uninstalling -678 didn't solve the issue. also removed -681 and it worked again, so either a combination of both or only 681 causes this issue.
since the client is going to be in use right now can't investigate any further and my dev system did not install the update yet.
long story short:
Remove KB4041678 & KB4041681 to get it working again
Investigating now:
Error happens upon opening the connection.
There are no more details sadly and i'm no expert on OLEDB / JetEngine, but according to wikipedia ACE 12 supports everything that OLE 4 does, so shouldn't it be possible to simply switch
ExcelUtilities.cs Line 48
if (args.DatabaseEngine == DatabaseEngine.Jet)
connString = string.Format(
@"Provider=Microsoft.Jet.OLEDB.4.0;Data Source={0};Extended Properties=""Excel 8.0;HDR=YES;IMEX=1""",
args.FileName);
connString = string.Format(
@"Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties=""Excel 12.0;HDR=YES;IMEX=1""",
args.FileName);
connString = string.Format(
@"Provider=Microsoft.ACE.OLEDB.12.0;Data Source={0};Extended Properties=""Excel 12.0;HDR=YES;IMEX=1""",
args.FileName);
If you have access to the source code of the application using linqtoexcel, you could also define the Engine when creating the ExcelQueryFactory like this:
using (var eqf = new ExcelQueryFactory(@"") { DatabaseEngine = DatabaseEngine.Ace })
i'll try to run the tests in a second to find out if there is any case that does not work with the solution.
Per October 10, 2017—KB4041681 (Monthly Rollup)
Security updates to 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.
Per October 10, 2017—KB4041678 (Security-only update)
Security updates to 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.
So, both potentially are the cause.
Hmmm... looks like other people are having issues with these recent patches (i.e. Microsoft broke something).
My recommendation would be to uninstall the following patch(es):
Patches
JET DB engine, Office shortcuts
In the blog there is this comment , which indicates that Excel files can no longer be linked to Access.
Since the last windowsupdate 10.10.2017, it is no longer possible to link excel files to Access 2000, or to open linked excel files
Since the last Windowsupdate 10.10.2017, it is no longer possible to link Excel files with Access 2000 or to open linked EXCEL files with Access 2000.
And in this comment there is a confirmation or a reference to an Excel database error.
Hello DKPrince,
we probably have the same problem here.
On all Windows 7 computers, we process address databases here, the database .xls can not be >> opened everywhere, since it is said to have no data fields.
In Excel itself, the address lists can be opened without problems, only if we want to link you for the serial letter creation comes a database error.
With .xlsx it goes immediately and with a conversion into a .csv it goes likewise. But we need machine-engineering .xls lists and this is a violent problem.
If someone has a solution, I am grateful for every tip.
Which patch do you have to uninstall again and how do you do it best?
The security updates for Windows 7 / 8.1 (October 2017) , the blog post, mentions that Microsoft patches the Microsoft JET Database Engine with KB4041681 and KB4041678 (Windows 7) as well as Update KB4041693 and KB4041687 (Windows 8.1). This is to close the following safety gaps.
CVE-2017-8717 - Microsoft JET Database Engine Remote Code Execution Vulnerability
CVE-2017-8718 - Microsoft JET Database Engine Remote Code Execution Vulnerability
In this heise.de forum post , however, a user complains that the Excel access in C # over Microsoft.Jet.OLEDB.4.0 no longer works. The error 0x80004005 (denied access) is reported when accessing the database driver in System.Data.OleDb.OleDbException . Also at askwoody.com there is this comment , which complains a broken Microsoft.Jet.OLEDB.4.0 database interface. No XLS files can be imported into an application (see also this article ). I am currently telling you that the problem for the above problems is to be found here.
Also here:
Problem importing XLS files
If you 're looking at problems importing XLS files into your applications, you are not alone. See this anonymous post on AskWoody:
Windows 7 for x64-based Systems KB4041681 and 2017-10 Security Only for Windows 7 for x64-based Systems KB4041678.
Yesterday we got bombarded with the problem that we can not import to xls file into our application, which we have been doing since forever. It gives an error: Unexpected error from external database driver (1). We dug deeper and discovered
Provider = Microsoft.Jet.OLEDB.4.0; DataSource = {0}; ExtendedProperties = \ "Excel 8.0; HDR = Yes; IMEX = 1 \"
Does not work anymore. After all, we'll get back to normal.
More here:
https://social.technet.microsoft.com/Forums/en-US/55b1d633-b715-491e-917e-b7cb01ae0523/error-in-windows-update-kb4041681-unexpected-error-from-external-database-driver-1?forum=sqldataaccess
Problem after windows update
Problem after windows update (Microsoft.Jet.OLEDB.4.0 no longer works)
Oct 14, 2017
This blog article popped up about this issue. It does confirm that this was an unintentional breakage, and that Microsoft is working on a fix:
This update (released October 10th, 2017) includes a security update release that inadvertently affects the JET 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.
The article of course recommends switching to ACE since Jet was deprecated 15 years ago. To me it doesn't make sense to hack LinqToExcel to try to switch its default to use ACE instead of Jet. It makes more sense to completely remove support for Jet, and make ACE a hard requirement. Because this move removes support for a technology (in a sense), I think this should be a LinqToExcel version 2.0 sort of thing.
Look for a new release of LinqToExcel in the near future.
It looks like using the Ace engine prevents me from using GetColumnNames. Any workaround?
This should not be the case. The latest master uses Ace, and it does not seem to be an issue there.
This should not be the case. The latest master uses Ace, and it does not seem to be an issue there.
The latest master is not the version 1.11 available through NuGet?
On Nov 13, 2017 4:44 PM, "Eric Moreau" ***@***.***> wrote:
This should not be the case. The latest master uses Ace, and it does not
seem to be an issue there.
The latest master is not the version 1.11 available through NuGet?
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<
#124 (comment)>,
or mute the thread
<
https://github.com/notifications/unsubscribe-auth/ATKYhu9DUCVhG8sRVUf-OvAgdvbvC8VBks5s2Lg4gaJpZM4P1i4t>
Windows Fixes
Please give these Windows patches a try, and let me know if they resolve your Jet issues.
(source)
Windows Patch(es)
Hi. Can you throw some advice here? I compiled from your master branch the linqToExcel, Remotion.dll, Remotion.Data.Linq.dll that it compiles as it seems from the above that you believe your master branch is resolving the Jet Database Error.
My Unit Tests are passing using both a csv and an xlsb. When I try and do the exact same thing from my console app I get the following:
"System.Data.OleDb.OleDbException
HResult=0x80004005
Message=Invalid argument.
Source=System.Data
StackTrace:
at System.Data.OleDb.OleDbConnectionInternal..ctor(OleDbConnectionString constr, OleDbConnection connection)...."
My Console app is building x86 the same as my unit tests. I cannot get this thing to work.
Any idea on what might be going on. I haven't applied the 954 patch for windows 10 as it seems you indicated there was a fix in your master.
Thanks