VistaDB

[WellitonToledo]

Any plans to work with VistaDB database?

[Mimetis]

Good idea.
Seems not very complicated.
I guess we can work from SqliteSyncProvider as a baseline

PR are open, by the way :)

[Mimetis]

Hey @WellitonToledo

I've looked into VistaDB, but since it's not free to use, and we need a licence to use it, I won't be able to develop the provider
Anyway, it seems to me that the SqliteSyncProvider should be easy to modify for VistaDB

[kendallmiller]

@Mimetis We're happy to provide free licenses to folks developing providers and other tools that use VistaDB. If you send your email and the project name to support@vistadb.com we'll set you up and provide free support as well!

[Mimetis]

Hey @kendallmiller

Thanks for your kind help.
The DMS solution contains the core services and all the providers (SQLite, SQL Server, MYSQL ...)
Each provider is a .csproj project, that compiles once the required packages are restored.

I imagine that adding VistaDB can be quite easy IF I have licence.
But what will happen to anyone that will clone the solution locally ?
Will they be able to compile the solution if they don't have any VistaDB license ?

I mean, adding a Nuget package exposing the VistaDB endpoint was the first thing I searched on Nuget, but I did not find anything
IF I need to install VistaDB to be able to compile the VistaDBSyncProvider, it could lead to a lot of misunderstanding from the community and will raise a ton of issues on Github.

Am I correct or did I miss something ?

[kendallmiller]

You're correct that there isn't a public, free version of the VistaDB provider library. We do provide NuGet packages for VistaDB, but only as part of our licensed installation. For us it's been a balance of risk - we haven't put restrictions in the engine itself to eliminate risk for production deployments but it means we have to be careful about distributing the engine library itself.

In your scenario it would likely take having the VistaDB provider outside of the solution so it doesn't block the main solution. An alternative would be to use the ADO.NET base classes instead of the provider-specific classes for operations - since those would always be present the system would compile, it just wouldn't be able to run VistaDB-specific tests without the VistaDB assembly around.

[Mimetis]

In your scenario it would likely take having the VistaDB provider outside of the solution so it doesn't block the main solution.

This is actually the case. All the providers are ADO.NET provider based.

All the abstract DB... objects are defined in the DMS core services.
The concrete providers are the concrete implementation of these abstract classes.

For example, we have a ad DbTableBuilder that is only using base classes from System.Data.Common (like for instance DbConnection and so on...)

And then we have the concret class SqlTableBuilder in the SqlServerSyncProvider. (and same for all the others providers)

I understand that creating multiples solution files can resolve the compile problem, but it will add a level of complexity for end users (Which .sln should I open ??)

I'm really interested to implement the VistaDB provider (and in my opinion, it could be done quite easily and fast) but I need a robust solution for anyone that come here and wants to clone / build / test the solution.

Are you considering at some point, to provider a free nuget package, with limited functionalities, in a near future ?

[pd365]

I would like to see this happen. Perhaps a paid solution for VistaDB only? I would be willing to pay for this sync functionality.

[kendallmiller]

From the last feedback, I'm wondering if any reference to the VistaDB engine would be required at all or just customizations to the SQL that's generated. If we could have it so the entire solution is buildable, but the VistaDB provider can't be tested unless you have a VistaDB license would that work for folks? Perhaps mark those tests as optional or ignore?

[Mimetis]

If we start from the SqliteSyncProvider project as a baseline (supposing that VistaDB will NOT be used as a server side, but mostly as client side), I guess the SQL customizations will be fast to convert / create.

But as you mentioned, we won't be able to run any tests on VistaDB.

It would be fine, if we were on a stable version, but I'm still making some minor changes, that prevent me to be 100% confident on the code, without having the tests passed on each iteration.

If I can't create the VistaDBSyncProvider project inside the whole solution, I won't be able to guarantee that it will be maintained over the time.

And of course, I won't be able to create and provide a nuget package.
So far any developer who wants to use it, will have to grab the code and compile it locally.

We can give it a try, since at least 2 people wants to try it :)

@kendalmiller, just a couple of question:

• How can we proceed to have a development license for VistaDB ?
• What will happen if I accidently commit the project with the VistaDB assembly embedded ?

[kendallmiller]

@Mimetis Just sign up for a free trial and let me know and we'll switch your license over. That gives you notification of updates but you won't be in our sales pipeline.

If the assembly gets committed to Git well.. We ask you do a deep remove of the assembly so it's not easy to get to but we recognize things happen and we always err on the side of supporting our customers and making things as easy as we can over locking down our IP.

[kendallmiller]

I would recommend a first attempt trying to treat VistaDB like SQL Server not SQLite; it uses a subset of the SQL Server T-SQL dialect and there's nearly always a "middle ground" that works with both (that's our key value prop!). For example, when we create ORM providers (e.g. Entity Framework) we start with SQL Server.

[Mimetis]

@Mimetis Just sign up for a free trial and let me know and we'll switch your license over. That gives you notification of updates but you won't be in our sales pipeline.

Done, I've just applied, using my professional email (@microsoft.com)

Let's give it a try !

[kendallmiller]

If you check your account at my.vistadb.com you should see a new permanent license for you. I'll get you pulled out of our trial workflow as well. Feel free to contact support for vistadb.com with any questions!

[Mimetis]

Thanks @kendallmiller !

I will keep you updated once the VistaDBSyncProvider is ready :)

[pd365]

Thanks @Mimetis @kendallmiller for moving forward on this.

[VagueGit]

We will investigate the VistaDb provider when available as we have struck issues with inconsistencies between SQLite and SQL Server which currently block us from using DMS in our projects.

[abutler77]

Any update on the VistaDb provider? I am also interested in this.

[CarstenVogelsang]

Hello @Mimetis!

I am also very interested in a VistaDB provider.

Due to the 99% similarities in SQL syntax and datatypes, the Dotmim.Sync.SqlServer project could be the best starting point for a port?! Every ADO.NET SQL Server object seems to have a similar VistaDB equivalent.

Are you still thinking about / working on a VistaDbSyncProvider?