New Features in This Release

.NET 6.0 Support

The VistaDB NuGet packages now include builds for .NET 6.0. The build target for net5.0 is still provided in this version, but may go away in future releases because Microsoft ended support for .NET 5.0 on May 10, 2022.  .NET 6.0 is considered the Long Term Support version for this set of API's and applications targeting .NET 5.0 should be planning their migration to .NET 6.0 per Microsoft’s long-term support policy.

AES256 Encryption

VistaDB has used AES128 since version 5 to encrypt database pages when a password is specified to enable encryption.  Starting with version 6.4, VistaDB will now use AES256 to encrypt database pages for new databases.  VistaDB 6.4 will upgrade encrypted databases from AES128 to AES256 when a PackDatabase or RepairDatabase is performed. 

VistaDB 6.4 can open and write to VistaDB 6.* databases encrypted with AES128 and will not upgrade their encryption unless a PackDatabase or RepairDatabase is performed.

Selecting Passwords for AES256

While shorter passwords may still be used (particularly with a test database where security is not really a concern), a longer password with more “entropy” would be required—about double what was required with AES128—in order to actually provide the greater security.  For example, a Base64 encoding (or hexadecimal encoding) of 32 randomly-generated bytes (32 * 8 = 256).

Performance of Encrypted Databases

While AES256 itself is slightly slower than AES128, the way database pages are each encrypted as a block makes the overall performance impact of this change minimal—and likely negligible—compared with an AES128-encrypted database.

Breaking Changes

Fixes to the VistaDBConnection.GetSchema method for “tables” (see below) can result in different tables being returned. When the restrictionValues array argument specifies a tableType value of null (no restriction on tableType) or “SYSTEM_TABLE” and should include any system tables, the [database schema] system table was not being returned in error.  This defect has been fixed and the [database schema] will now be included.

If the [database schema] system table is not desired in the returned collection, the tableType value at array index 3 in the restrictionValues argument can be specified as “BASE TABLE” to return only normal (non-system) tables.

Issues Fixed in 6.4

Engine

• Fixed: Using the unary operators minus (-) or bitwise-not (~) directly on a column reference can alter the internal store used for other references to the same column, causing incorrect results and potentially unpredictable filtering.
• Fixed: VistaDBConnection.GetSchema("tables", ...) may not return any tables when both a tableName and tableType are specified (non-null) in the restrictionValues array argument, even when there should be a match as specified.
• Fixed: VistaDBConnection.GetSchema("tables", ...) does not list the [database schema] system table when it should be included in the returned collection.
• Fixed: Setters for VistaDBCommand properties CommandText and Connection can fail with a VistaDBException with error number 1015 and a message about “overlapping use” when the instance is idle but currently points to a VistaDBConnection which is immediately executing for a different VistaDBCommand instance.
• Fixed: The IVistaDBDDA.OpenDatabase method and the IVistaDBDatabase.OpenTable method may fail with an exception message such as “Collection was modified; enumeration operation may not execute” or “An item with the same key has already been added” when being called from multiple threads (even with separate instances), due to a race condition. This might also affect related ADO.NET usage, which uses these methods internally.
• Fixed: Row lock via IVistaDBTable.Lock(long) may not be released properly by IVistaDBTable.Unlock(long) if IVistaDBTable.Post() had not been called, until the IVistaDBTable is disposed.

Data Builder

• Fixed: Data Builder will not auto-open a VistaDB database which has a custom filename extension (other than .vdb6) when passed as a command-line argument.  This includes double-clicking the database file.

Known Issues

Visual Studio

• Extension Doesn't Automatically Install If Visual Studio is Running: If any instance of Visual Studio 2017 or later is running when the installation runs the VistaDB extension will not automatically install into Visual Studio.  To manually install, double-click VistaDB.VSDesigner.15.vsix (for Visual Studio 2017 / 2019) or VistaDB.VSDesigner.17.vsix (for Visual Studio 2022) in the C:\Program Files (x86)\Gibraltar Software\VistaDB 6\Bin directory (by default)