-
Notifications
You must be signed in to change notification settings - Fork 41
Upgrade provider and test code to 3.1.x #41
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…ble `JetConfiguration.OleDbDefaultProvider` for database create operations.
Introduce some helper extension methods to access well defined OleDb properties, that `DbConnectionStringBuilder` knows nothing about.
…nt." This reverts commit 25f8685.
|
@lauxjpn Looks like you might want to consider changing the following line in NuGet.config to be I'm not sure what the difference is, but someone at Microsoft just linked the second one in one of the issues, so I'm guessing that the first one is an older (but still working) version of the nightly feed. The |
|
@FreddyD-GH Thanks! I was wondering today, why your dotnet/runtime#32573 fix wasn't yet part of the nightly-builds and implemented a dummy transaction class to ignore the error for the time being. BTW, I will push the test projects tomorrow. They should be compiling. I fixed a couple of tests and provider code issues that came up because of them. |
The Jet DatabaseModelFactory class needs to be checked and tested and its code similarity to the SQL Server provider should be increased.
The `JetMigrationsSqlGenerator` class needs to be thoroughly checked and tested.
|
I did not read about the OleDb issue. If the transaction get closed (commit/rollback) also with the issue (and so we can just ignore the error), the whole OleDb provider is wrapped by System.Data.Jet (the only thing that is not wrapped is the Connection Builder). If you think that is better to use the "stable" version of OleDb we can work in |
|
From my point-of-view, the PR is good enough to be merged. I will leave it open for about 48 hours for anybody to review the code and will merge after that, if there are not objections. |
…od to JetCommand.
ac58b4a to
bd708a3
Compare
Use `ReleaseComObject()` instead of `FinalReleaseComObject` to avoid creating stale references to the RCW of a potential singleton COM object.
This is a work-in-progress PR to upgrade the provider code (without the tests as of now) to EF Core 3.1.x. That means, that this PR can still change/be rebased/force-pushed without warning.
I removed most SQL Server-only code that had no corresponding implementation in Jet. Some smaller parts might still exist and should be cleaned up over the next iterations.
I also kept the codebase relatively similar to its EF Core 2.2.x origin, though a couple of method call translations should be corrected. They should come up again in a couple of test cases.
I also added some
TODO:andCHECK:flags in the codebase, that should be revisited before going GA.This PR is tracked by #34.