VistaDB 4 includes a number of improvements to SQL syntax, engine enhancements, and many API changes.
The VistaDB Edition Differences page should help explain most of the changes in the versions of VistaDB that are available.
Data Builder 4 includes syntax highlighting
Data Builder now uses the fantastic Actipro Software ActiPro SyntaxEditor control for syntax and colorhighting in the SQL Editor dialog (and some others).
This change provides a much more user friendly SQL Editor with support for collapsible regions, find and replace, goto line, block comment and uncomment, and many more features.
Our customization of the syntax editor includes colors to match closely what users are already familiar with in SQL Management Studio, and includes new hot key support for things like ctrl-e for execution.
Works with Windows 7
VistaDB 4 has passed all the Windows 7 compatibility tests from Microsoft! SQL Scripts are now kept beside the target database by default (same directory), but you can override this directory as well. The default for all scripts now uses the Public Document Library in Windows 7 to avoid UAC issues for users.
We currently run Windows 7 64 bit internally on most developer workstations, and test the 32 bit version in Virtual Machines. We have found that Windows 7 performs very well with VistaDB 4.
AssemblyVersion vs FileVersion
VistaDB 4 uses a new schema for versioning the numbers of the assemblies similar to how Microsoft versions the system assemblies for .Net. The AssemblyVersion attribute will stay 4.0.0.0 for all builds that implement the interfaces to be compatible with 4.0. The individual builds have a FileVersion attribute set that includes their specific build (4.0.6.1).
The list of VistaDB Assemblies in the GAC shows that the 3.x line included the build number. This would often cause problems with applications built against one version, but that now need to run under another (ORM and other third party tools).
Looking in the GAC you will find an entry for VistaDB.4 that shows 4.0.0.0. That is to avoid the whole binding redirect problem of the 3.x line. This also means you can only have a single 4.0 assembly in your GAC at a time (avoiding build binding problems). If you want to see the specific FileVersion of the assembly you can right click the entry, select properties and then view the Version tab. It should look something like the entry shown.
Entity Framework Supported
VistaDB 4 introduces support for the Entity Framework (EF). The Entity Framework can greatly simplify writing Data Access Layers (DALs) for your managed applications.
By using the EF you also gain the ability to use LINQ to Entities to query your VistaDB database. The LINQ syntax is an incredibly powerful way to write queries against a database in your .Net language of choice.
The initial release of our EF provider is definitely nascent technology – it is still under development. We plan to continue to improve the support and features of the EF provider over the lifetime of the VistaDB 4 product.
SQL Server Compatibility Changes for CLR Procs and Functions
We have added a new VistaDB.Compatibility class to make it easier to transition SQL Server CLR Procs to VistaDB (and back again). We have renamed the enumeration members and contexts to match SQL Server naming more closely.
Now through only changing the using statements at the top of your CLR Proc you should be able to run in both database engines.
ClrProcedures now use the [SqlProcedure] and [SqlFunction] attributes exactly like SQL Server. The one change that many will need to make is to use the System types in their clr procs rather than the SQL Data types. Using the system types (string, int, etc) ensure that the code is more portable.
Better Medium Trust support
VIstaDB 4 includes a number of enhancements for websites running under Medium Trust. Medium Trust compliance is a very difficult objective for something like a relational database. We have managed to allow all of our features (including temp tables, Sql procs, and Clr Procs) to run under Medium Trust. Users can even pack their database directly from Medium Trust in order to perform database maintenance without first needing to download the database.
New Installer based on Tarma
We have updated our installer to use the Tarma Installer. The installer is very easy to use, can be automated from command options, and provides us with great customization abilities for running things like the EF install system.
Tarma has been great to work with from a company standpoint as well. I have opened a few tickets during our migration from the previous installer and they have always been very responsive. Updates from Tarma are also often and painless to install. The product tells you that an upgrade is available and you can choose to download it.
Breaking Changes from 3.x
We have a revision philosophy that should minimize breaking changes within customer applications as much as possible between revisions.
VistaDB 4 is a major release because we had to make a number of breaking changes to the interfaces. Anytime you revise an interface it should be a major change in your product version.
We strive very hard to make sure minor versions are small changes in behavior or features. Any product built against a 4.0 should expect to run on all of the builds for that major.minor. When VistaDB 4.1 comes out you should expect some minor breaking changes, perhaps additional interfaces or overloads. We should not break any of the interfaces though until we release a 5.0.
This allows you to be confident that any build for 4.0 should be compatible within your application.
Upgrading from VistaDB 3
First, remember that you can run 3 and 4 in side by side mode. There is no reason to remove 3 in order to install 4. You can use the Visual Studio Designers for both without conflict. Visual Studio 2008 and higher are the only ones supported in 4.x, you can load the assemblies in Visual Studio 2005 if you don’t need any design time support and are working on a .Net 2 SP1 project.
Upgrading from VistaDB 3 to 4 should be considered a complete retest and revalidation of your product. It is, after all, a major change. Some of the interfaces have changed behaviors. The largest changes are in Direct Data Access (DDA) interfaces. We have encapsulated more of these interfaces to ensure that users cannot manipulate the internals of the objects. There are users who were forward casting the interfaces to their underlying types and modifying their contents, this should always result in an exception as it was not the intended design of the class. If you think you need access to the internals of an object there should always be a way to get that information through other means, not manipulating the object directly. In some cases this would lead to bad application behavior, and in others it would lead to database corruption (since the objects were not intended to be used that way).
License Changes
Make sure your application has a licenses. licx in the executable. The entire license system has changed in 4, so you may want to read through the help section on “VistaDB Licensing” to see how your project is effected. Every developer who compiles any part of the application must have a valid developer license on their machine. This was not enforced in 3.x, but it is now in 4. There is no such edition where only the “database guy” needed a license. The license is built into the executable on the machine it was built, so machines without licenses cannot build.
We will be offering build machine licenses for things like MSBUILD, or continuous integration machines at a reduced price. But they will not be able to be used on full developer machines – they are intended for automated compiles only.
ADO.NET is easiest transition
ADO.NET code should be the easiest to migrate from 3 to 4 as the interfaces are well defined. We have added new overloads in some cases, and updated some behaviors, but the majority of code should run unchanged.
Pagesize limits
See the blog post on upgrading VDB3 files for detailed information on migrating a VDB3 database to VDB4. The database may need to be changed as a result of the pagesize enforcement changes in VistaDB 4. You can view a list of the pagesize limits on the website.
Applications were being submitted to us all the time with complex requirements, but their pagesize set to 1. This led to a lot of wasted tech support time trying to discover problems that were due to incorrect structure of the data. In VistaDB 4 we have implemented these hard limits to help avoid those designs being implemented before the problems arise at runtime.
If you are attempting to upgrade a database and it fails, the most likely cause is that your pagesize is 1 and you have more entries than the limits allow. The other most likely cause is that you have invalid defaults for columns (DATE is a datatype now, not a function to get the current date – GETDATE() is that function in SQL Server).
DDA Interfaces changed
Many of the DDA interfaces had a property to let you get a list of the tables, indexes, etc. Those were not the actual tables, but a copy of the table list to be enumerated (not modified). Many of the interfaces were returning classes that could be forward cast to concrete implementations that were intended for internal use only.
As an example the list of default values are always contained in a IVistaDBDefaultValueInformation object that only exposes a few properties (ColumnName, Expression, UseInUpdate). Each of these are now read only in order to ensure the user knows that it is a read only collection of the values. Enumerating the list of default values is done from the IVistaDBDefaultValueCollection (which contains read only IVistaDBDefaultValueInformation objects).
You will see this pattern many times in the DDA interfaces, a collection of some objects that are information objects. This allows you to enumerate over the collections for each object, but many times you cannot modify them at that location. Look to the parent of the object. If you are modifying constraints, the table is probably the level that holds the routines to modify them. If you are adding columns, the TableSchema is the location to look.
Most of the changes in 3.x code should be fairly minor, unless your code was relying on bad behavior (like forward casting).
Read the changes through the blog
The complete history of the changes can be read by following through the BUILDS category on the blog.
Online Help files Updated
The VistaDB 4 Online Help Files have been updated to include the final shipping version of VistaDB 4. The entire VistaDB.net website has been updated to include the information for VistaDB 4.
Subscribe