Getting Started - What's New - Version 6.6
In This Topic
.NET Framework 4.5.1 or Later Required: VistaDB 6 does not support versions of .NET older than 4.5.1. You will need to first upgrade your application to target .NET Framework 4.5.1 or later before upgrading to VistaDB 6.
New Features in This Release
.NET 9.0 Support Added
The VistaDB NuGet packages now include assemblies targeting .NET 9.0 where relevant.
Data Builder Integrated Backup & Restore
The Backup and Restore API commands added in VistaDB 6.5 are now available in the Data Builder UI. You can select the Backup and Repair options from the Database menu.
SQL Multi-row Insert Syntax
The VistaDB Engine now supports multi-row insert syntax consistent with SQL Server. The VALUES clause now allows multiple rows of values with commas between each row of comma-separated values enclosed in parentheses.
For example:
INSERT INTO Products
(ProductId, ProductName, UnitPrice, InStock)
VALUES
(1, 'Coffee', 9.99, 1),
(2, 'Tea', 4.99, 1),
(3, 'Hot Chocolate', 5.99, 0),
(4, 'Green Tea', 6.99, 1);
SQL Constant Literal Type Changes
Schema determination from constant literals has been corrected to better match SQL Server. This may require changes to how some query values are retrieved as using the wrong type can cause an exception.
For example:
SELECT 42; //Previously returned BIGINT, now INT
SELECT 2147483648; //Previously returned BIGINT, now DECIMAL
This may be a breaking change for applications expecting a specific type from queries returning literal values. ADO.NET returns value types (like Integer and Boolean) boxed in Objects. Depending on how your application is converting them to local variables for use you may experience a runtime exception due to a change in the boxed type from System.Int64 to System.Int32 for example.
Number Literals
- Numbers without decimal points or exponential notation will now be considered to be INT unless they are too large for that type in which case they will be treated as DECIMAL (to match SQL Server’s NUMERIC) — both cases were previously considered to be BIGINT.
- Numbers with decimal points but without exponential notation will also be considered to be DECIMAL—these were previously considered to be FLOAT.
- Numbers with exponential notation will be considered to be FLOAT, as before.
String Literals
String literals specifying N will be considered to be NVARCHAR while other string literals will be considered to be VARCHAR —these were previously considered to be CHAR. This will not affect how strings are read from results, but it could result in differences in value handling within scripts if the default schema of a string literal is relied upon instead of being forced by a CAST or CONVERT, and so on.
Binary Literals
Binary literals (hexadecimal) will be considered VARBINARY instead of IMAGE (aka VARBINARY(MAX)). This will not affect how these binary results are read, but it does mean the value is limited to 8000 bytes.
Issues Fixed in 6.6
We're now sharing our internal defect tracking number as part of each resolved issue so you can associate these items with information provided by our support team. The number indicated is assigned by our work item tracking system, so gaps in sequence typically reflect other tracked items (like user stories, features, etc.) or defects that were introduced and resolved within the release.
Engine
- Issue 1276 Fixed: Fixed: @@ROWCOUNT and ExecuteNonQuery can sometimes report an incorrect count of affected rows when executing a multi-statement batch.
- Issue 1390 Fixed: Schema determined from constant literals does not match SQL Server’s handling. Affects numbers, strings, and binary (hexadecimal) values.
- Issue 1393 Fixed: Text column position reported in syntax errors can be inaccurate when tabs characters occur in the text.
- Issue 1394 Fixed: BackupDatabase method fails when database file is opened as an IVistaDBDatabase used to then create a VistaDBConnection instance.
- Issue 1395 Fixed: BackupDatabase(string) method can fail after creating an empty archive file when an incompatible Open Mode was used.
- Issue 1407 Fixed: VistaDBConnction.RestoreDatabase method fails to restore databases larger than 2GB
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)
See Also