Optimizations in how single and multi-process locks are implemented provide significant performance improvements. The Single Process open modes benefit the most from these changes since they run entirely in-process. Compared to Version 6.1, the new implementation is between 20 and 45% faster. The more rows the engine must check to complete the query the higher the advantage, so joins between larger tables benefit the most.
Multiprocess open modes can benefit from these same improvements in some cases, but typically the overhead of using file system locks is such that the gains are more limited.
The Single Process open modes have been further optimized for high contention (multiple readers and writers) scenarios.
No code changes are necessary to take advantage of this improvement if your Single-Process application is already using SingleProcessReadWrite or SingleProcessReadOnly open modes. (SingleProcessReadWrite is the default if no Open Mode is specified in the connection string.) If your application fits the criteria for Single Process open modes (you only have one process that needs to access the database at a time) your application will see significant benefits from using these modes compared to the Multiprocess open modes.
A public PageSize property is now available on a VistaDBConnection instance when a database is open. This makes it easier to obtain the PageSize for an existing database. To change the PageSize, execute a PackDatabase. This rewrites the entire database with the new (Larger or smaller) page size. The limitations on the number of objects and size of some items is determined by the page size.
Because of these breaking changes, the assembly version for the VistaDB engine has been updated to 6.2.0.0.
The VistaDBCommand.ExecuteScalar method now follows the ADO.NET specifications for handling NULL values. A .NET null is returned if the results are empty. A DBNull.Value is returned if the first column of the first (non-empty) result is a NULL. It previously returned a .NET null in both cases. This change was made to match the exact behavior of SQL Server in ADO.NET.
The @@IDENTITY variable and the Scope_Identity() function now use return type VistaDBType.Decimal (instead of VistaDBType.Int) to correctly handle BIGINT identity columns and to more consistently match the NUMERIC(38,0) return type in SQL Server. This can require different handling—such as when returning the value using ExecuteScalar(). This change was made to match the exact behavior of SQL Server in ADO.NET.