The VistaDB Engine now ships with a .NET Framework and a .NET Standard build. The .NET Standard assembly should be used for Xamarin on any platform as well as .NET Core. This simplifies using VistaDB in shared libraries that are intended to work cross-platform by eliminating the individual builds for Xamarin Android, iOS, and Mac.
To make it easier to use VistaDB in new projects that target multiple versions of the framework the VistaDB assemblies are provided as NuGet packages for local use instead of as individual assemblies.
VistaDB 6 natively supports async/await asynchronous database operations, making it much easier to create responsive UI applications that interact with databases. Instead of writing your own code to put operations that could block on a background thread so your UI stays responsive you can just await the call to VistaDB. While the engine is working on your request your thread can go back to other UI actions.
As an embedded database, VistaDB is usually processor bound. To make async operations effective we've pushed all the hard work the engine does off to a background thread (and more, see below).
The VistaDB engine now uses multiple threads to process queries where the overall query can be broken into multiple stages that can be processed independently. For example, subqueries will be run on their own threads and then are merged with the outer query to significantly improve subquery performance. Even queries that don't break down into stages will be run on a separate query from the calling application to support async processing and enable a modest amount of concurrent work with Data Readers and ORM's.
A new query governor to make sure the engine won't use too many threads and overwhelm systems with few cores or a large number of concurrent operations in the same process.
Previously, VistaDB used file locks when running in any mode that allowed multiple writers. For version 6 VistaDB supports a new access mode that uses in-memory locks. This is dramatically faster and will narrow the performance gap between exclusive mode and non-exclusive read/write mode, particularly for the very common scenario of a single process accessing a database.
To use this feature, an application needs to specify the Single Process Read/Write access mode, which is now the default access mode.
To simplify use with a range of project types, all VistaDB assemblies are included as NuGet packages. This makes it much easier to take advantage of the new .NET Standard support and have shared projects used by different target frameworks from Xamarin iOS through .NET Core. When updating references for existing VistaDB applications it's recommended that you remove the old assembly reference and add the new package. For more information, see NuGet Packages for VistaDB.
VistaDB 5 and VistaDB 6 can be installed on the same computer side-by-side. To fully use databases with VistaDB 6 they will need to be upgraded, however VistaDB 6 can also view databases in read-only mode without them being upgraded.
The new faster locks for single applications mean upgrading applications using Nonexclusive Read Only or Nonexclusive Read Write (the previous default) should decide whether to switch to the new Single Process or Multi Process modes. If you are confident only one process will be accessing your database at a time we recommend switching to Single Process for it's major performance improvement. If not, select the relevant Multiprocess mode.
| If You're Using.. | And Meet This.. | Switch To.. |
|---|---|---|
| NonexclusiveReadOnly | Only one process uses a database file at a time | SingleProcessReadOnly |
| More than one process can use a database file at a time | MultiProcessReadOnly | |
| NonexclusiveReadWrite | Only one process uses a database file at a time | SingleProcessReadWrite |
| More than one process can use a database file at a time | MultiProcessReadWrite |
Follow the upgrade instructions to change connection strings to use the VistaDB 6 provider and change any typed Data Sets or Entity Framework EDMX models as appropriate.