-
Notifications
You must be signed in to change notification settings - Fork 649
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
Delete SAP SqlAnywhere #1218
Comments
I'm afraid it has been dead technology for many years. The previous company I was working for still uses it for the on-prem software, so that's why I added support for SQL Anywhere to FluentMigrator. However, I don't work there any more, and I doubt that I'll ever get into this DB again. I had contact with some internals of SQL Anywhere, and I mentioned this project and that I had built support for their technology, but they didn't show any interest. I doubt that they will ever support .NET Core, as there was hardly support for the original Entity Framework. BTW, here's a request to have Microsoft build EfCore drivers for SQL Anywhere, something that they of course won't spend resources on: dotnet/efcore#12153 I suppose it's up to those who still depends on SQL Anywhere to build a community driver. I support your suggestion to move the tests into a separate csproj. |
If we restructure dependencies, as described in this thread, we'll some time in the future be able to get insight into the usage per provider from the download count at nuget.org. If some providers stay at 0 downloads for a few version, we could consider dropping the support for those providers. |
This is the latest SQL Anywhere stuff on NuGet. Version 17 of the driver is built for .NET Framework, and it may or may not work for .NET Core 3.X apps. It depends on the internal API calls, whether they are available in .NET Core 3.X. Pre .NET Standard 2.0, it would not even be possible to install a package like this into a .NET Core application. |
Thanks. I think the big thing is, once you see my PR for #1178 , you'll see how much of a PITA having SqlAnywhere tests live inside the main FluentMigrator.Tests project is, and why it took me hours to resolve all the compile errors when multi-targeting with |
TODO
Progress so far
|
I wrapped this up this morning, but haven't pushed it to my public fork yet. Will update comment above and then stage this change as FluentMigrator 3.3.1, after #1178 |
@jzabroski SAP has two former Sybase databases: SQL Anywhere (ASA) and Adaptive Server Enterprise (ASE). It seems that you can use ASA - according to this answhere here - the database from .NET Core over ODBC. There also seems to be an ADO.NET driver for .NET Core on nuget.org. I also found a .NET Core ADO.NET driver for ASE. Nothing official, but it still seems that there are people out there using the databases, so I guess that it'd be useful to keep the processor/dialect. |
If we want to support legacy databases via System.Data.Odbc, that is fine, but I think we need some basic sanity checks for what we consider maintainable:
My general thought is, we probably:
Step 2 is the painful part that I have not gotten a chance to complete. I think, rather than trying to do it all at once, we are probably best off doing it incrementally. |
However, it appears iAnywhere is on at least version 17 now, but the .NET Core package maintained by CodeRush only works up to 16. All things considered, we can experiment with using System.Data.Odbc rather than deleting SAP SqlAnywhere altogether. It is probably a much smaller lift to use the generic System.Data.Odbc interface than to actually remove SAP SqlAnywhere support altogether. |
I did a proof-of-concept of moving to System.Data.Odbc - it seems to work. Will hopefully ship it this week and wrap up 5.0.0 release. |
Decided to go ahead and just full on delete this lead anchor. Time to cast the sails and cruise away from .NET Framework. |
@eloekset Pushed. I bypassed PR for this, so let's see if it builds on the build server. If it does not, that is another adventure to go figure out. |
Looks like the GitVersion task has a dependency on .NET Core 3.1 maybe? |
I am cleaning that up now. UseGitVersion is deprecated in favor of GitTools. |
Got past that error. Fingers crossed I'm all set: https://dev.azure.com/fluentmigrator/fluentmigrator/_build/results?buildId=705&view=logs&j=12f1170f-54f2-53f3-20dd-22fc7dff55f9&t=53352b99-bc56-513f-dcdf-57009ff4318b |
.net core 2.1 isn't supported any more. It's been end of life for probably more than a half decade. What are you trying to accomplish? |
SapAnywhere is not support on .NET Core by SAP, and the test runner cannot run on .NET Core due to this limitation.
As part of #1178 , I've littered the code with
#if NET461
checks. I think Phase 2 should be to move the FluentMigrator.Tests related to SapAnywhere into their own csproj, and only run them on net461. This will likely make it more readable, and easier to delete if we eventually drop support for SapAnywhere.@eloekset Do you have any insight into whether SAP is still supporting SapAnywhere? My understanding is its mostly used in German and Scandinavian countries, so I thought you might be more an expert than me, as I've never used SAP-anything-anywhere-any-time :)
The text was updated successfully, but these errors were encountered: