Skip to content
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

Closed
jzabroski opened this issue Apr 12, 2020 · 19 comments
Closed

Delete SAP SqlAnywhere #1218

jzabroski opened this issue Apr 12, 2020 · 19 comments
Milestone

Comments

@jzabroski
Copy link
Collaborator

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 :)

@eloekset
Copy link
Member

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.

@eloekset
Copy link
Member

eloekset commented Apr 13, 2020

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.

image

If some providers stay at 0 downloads for a few version, we could consider dropping the support for those providers.

@eloekset
Copy link
Member

eloekset commented Apr 13, 2020

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.

image

@jzabroski
Copy link
Collaborator Author

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 <TargetFrameworks>net461;netstandard2.0;netstandard2.1</TargetFrameworks>

@jzabroski
Copy link
Collaborator Author

jzabroski commented Apr 19, 2020

TODO

  • Decide on name for common test project. I believe it should be named either FluentMigrator.Testing or FluentMigrator.TestFramework. I believe it should not end in *Tests as that would cause it to be picked up by dotnet test

Progress so far

  • Based off Version 3.x should support .NET Core LTS version(s) #1178 progress checked to my fork https://github.com/jzabroski/FluentMigrator
  • Updated AssemblyInfo.cs in various projects so that InternalsVisibleTo supports the new test framework project
  • Moved into FluentMigrator.Testing
    • IntegrationTestBase
    • IntegrationTestOptions
    • IntegrationTestOptions.DatabaseServerOptions
    • ValidationHelper
    • ValidationUtilities - this is actually in FluentMigrator.Abstractions but only used in the test project?
    • ServiceCollectionExtensions
    • BaseConstraintTests
    • Integration/Processors/BaseColumnTests
    • Integration/Processors/BaseIndexTests
    • Logging/TextWriterLoggerProvider
    • Integration/Processors/BaseSchemaExtensionsTests
    • Integration/Processors/BaseSequenceTests
  • Various ambiguous references
    • ServiceCollectionExtensions: CS0104 'ServiceCollectionExtensions' is an ambiguous reference between 'FluentMigrator.Testing.ServiceCollectionExtensions' and 'Autofac.Extensions.DependencyInjection.ServiceCollectionExtensions'
      • I chose our version, which I believe to be correct. Just logging it in case that is the wrong choice, and I suffer the consequences and can't remember a week later why things error out at run-time.
      • D:\source\GitHub\fluentmigrator\test\FluentMigrator.Testing\Unit\IssueTests.cs 38
  • Kept out of FluentMigrator.Testing
    • Logic in test classes starting with Obsolete
      • ObsoleteIntegrationTestBase
      • ObsoleteVersionMigrationTestBase
      • ObsoleteMigrationRunnerTests

@jzabroski jzabroski changed the title SapAnywhere tests need separate project SAP SqlAnywhere tests need separate project Apr 19, 2020
@jzabroski
Copy link
Collaborator Author

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

@fubar-coder
Copy link
Member

@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.

@jzabroski
Copy link
Collaborator Author

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:

  1. Does the database support a docker image or similar for integration tests to be run?
  2. Should we upgrade from supporting net461 TFM to net48 so that we can fully utilize net standard2.0 libraries like System.Data.Odbc? I don't think we should support System.Data.Odbc against net461. It's just asking for a lot of support tickets for legacy clients.

My general thought is, we probably:

  1. Bump FluentMigrator to v4.0 to allow for semver major breaking changes in API (dropping FluentMigrator.SqlAnywhere is a major API change)
  2. Finish merging the existing 4.0 branch with 3.0

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.

@fubar-coder
Copy link
Member

@jzabroski I personally don't mind dropping databases that aren't supported in docker, but I'm curious how you specify docker support?

  • Is there an official docker image?
  • Is there any unofficial docker image?
  • Can it run inside a Linux docker container?
    • Is it installable in a Ubuntu image with apt?
Database Docker Hub link
SQL Server https://hub.docker.com/_/microsoft-mssql-server
Postgres https://hub.docker.com/_/postgres
Oracle 12c https://hub.docker.com/_/oracle-database-enterprise-edition or https://hub.docker.com/r/quillbuilduser/oracle-18-xe or a custom registry with a Dockerfile from https://github.com/fuzziebrain/docker-oracle-xe
IBM DB2 https://hub.docker.com/_/ibm-db2-warehouse-dev or https://hub.docker.com/r/ibmcom/db2
MySQL https://hub.docker.com/_/mysql
MariaDB https://hub.docker.com/_/mariadb
SAP Hana https://hub.docker.com/_/sap-hana-express-edition
SQL Anywhere https://hub.docker.com/r/jaschweder/sybase or https://hub.docker.com/r/datagrip/sybase
Firebird https://hub.docker.com/r/jacobalberty/firebird
Microsoft Access (JET Engine) ???

Amazon Redshift might be a challenge...

@jzabroski
Copy link
Collaborator Author

jzabroski commented Dec 30, 2021

https://infocenter.sybase.com/help/index.jsp?topic=/com.sybase.help.sqlanywhere.12.0.1/dbprogramming/adodotnet-development-secta-3832474.html says:

SQL Anywhere .NET Data Provider features

SQL Anywhere supports the Microsoft .NET Framework versions 2.0, 3.0, 3.5, and 4.0 through three distinct namespaces.

  • iAnywhere.Data.SQLAnywhere The ADO.NET object model is an all-purpose data access model. ADO.NET components were designed to factor data access from data manipulation. There are two central components of ADO.NET that do this: the DataSet, and the .NET Framework data provider, which is a set of components including the Connection, Command, DataReader, and DataAdapter objects. SQL Anywhere includes a .NET Entity Framework Data Provider that communicates directly with a SQL Anywhere database server without adding the overhead of OLE DB or ODBC. The SQL Anywhere .NET Data Provider is represented in the .NET namespace as iAnywhere.Data.SQLAnywhere.

The Microsoft .NET Compact Framework is the smart device development framework for Microsoft .NET. The SQL Anywhere .NET Compact Framework Data Provider supports devices running Windows Mobile.

The SQL Anywhere .NET Data Provider namespace is described in this document.

To read more about how to access data stored inside a SQL Anywhere database using the ADO.NET object model, in particular via the Language Integrated Query (LINQ) to Entities methodology, see the SQL Anywhere and the ADO.NET Entity Framework white paper at [external link] www.sybase.com/detail?id=1060541.

  • System.Data.Oledb This namespace supports OLE DB data sources. This namespace is an intrinsic part of the Microsoft .NET Framework. You can use System.Data.Oledb together with the SQL Anywhere OLE DB provider, SAOLEDB, to access SQL Anywhere databases.

  • System.Data.Odbc This namespace supports ODBC data sources. This namespace is an intrinsic part of the Microsoft .NET Framework. You can use System.Data.Odbc together with the SQL Anywhere ODBC driver to access SQL Anywhere databases.

On Windows Mobile, only the SQL Anywhere .NET Data Provider is supported.

There are some key benefits to using the SQL Anywhere .NET Data Provider:

In the .NET environment, the SQL Anywhere .NET Data Provider provides native access to a SQL Anywhere database. Unlike the other supported providers, it communicates directly with a SQL Anywhere server and does not require bridge technology.

As a result, the SQL Anywhere .NET Data Provider is faster than the OLE DB and ODBC Data Providers. It is the recommended Data Provider for accessing SQL Anywhere databases.

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.

@jzabroski
Copy link
Collaborator Author

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.

@jzabroski
Copy link
Collaborator Author

Decided to go ahead and just full on delete this lead anchor. Time to cast the sails and cruise away from .NET Framework.

@jzabroski
Copy link
Collaborator Author

@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.

@eloekset
Copy link
Member

Looks like the GitVersion task has a dependency on .NET Core 3.1 maybe?

@jzabroski
Copy link
Collaborator Author

I am cleaning that up now. UseGitVersion is deprecated in favor of GitTools.

@jzabroski
Copy link
Collaborator Author

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

@jzabroski
Copy link
Collaborator Author

Missed a few net462 references. Added a new solution folder called build to prevent that in the future.

image

@ElDuderinoBerlin
Copy link

ElDuderinoBerlin commented May 15, 2024

There is indeed (meanwhile) a NetCore 2.1 driver. Where is the old source code to the SQL Anywhere extension?

2024-05-15 23_06_16-C__Program Files_SQL Anywhere 17_Assembly_Core2 1

Regards

@jzabroski
Copy link
Collaborator Author

.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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants