We have posted updates to all of the new SKUs released earlier this month.  Each SKU if present in your account will show the downloads in the VistaDB 4 area of the download site.

Each of the downloads below have been tested to work with Visual Studio 2008 and Visual Studio 2010.

Existing current account holders will have their existing product sku replaced with the new ones over the next few days.  Then you will see these in your download section.

There is no new engine build as a part of this update.

Addons vs Engine Builds

Add-ons will not be updated at each new build of the engine.  In most cases nothing changes in the Add on SKUs.  When we have changes in them we can now release them independent of the release cycle for the main engine. 

For now we will keep the same version number as whatever the current VistaDB 4 engine was at that time.  All of these downloads are flagged as Build 14 because that is when they were released.  But in the future they may skip several releases of the engine.  Only the most recent version of each will be kept in the download site to avoid confusion.

More...

Build #14

We are very pleased to release Build 14 of VistaDB 4.0.  There are a number of small fixes present, but the biggest reason for this release was that Build 13 had an installer bug preventing users from installing on 32 bit machines, or machines with only the TFS Shell installed (not the full VSTS, just the shell).  This was causing quite a few people to not be able to start their trial. 

Trial Users

We have reset all trial start dates from when Build 13 was released in order to give everyone a new trial window. 

When asked if you want to use your existing trial license click No, and enter your trial email address to get a new trial license.  It will expire 30 days from the day you get the trial license.

Server Explorer Nodes

We had to rotate a GUID for 4.x to avoid a conflict in 3.x (see below).  This results in all current Server Explorer nodes for 4 prior to Build 14 not working with Build 14.  Remove all VistaDB Server Explorer nodes prior to upgrading to avoid an error in Visual Studio after installing Build 14.  If you have already upgraded see the NOTES section below for details on how to fix this post install.

There was a conflict between VistaDB 3 and VistaDB 4 being used in strongly named datasets on the same machine.  This was due to one GUID in the DDEX provider not being rotated when we moved to 4.x.  After installing Build 14 or higher you can now have both side by side, but the 3.x install is broken after removing 4.0 prior to Build 13.  See the NOTES section below for how to repair your 3.x install.

More...

Build #13

This build has a lot of minor changes from user tickets, but the major update is for Visual Studio 2010 RC.

Visual Studio 2010 RC

Visual Studio 2010 RC now works.  There were several changes in Visual Studio between beta 2 and the RC with respect to data providers and plugin installation.  We have fixed these issues. 

Hopefully the Visual Studio 2010 final release will not introduce any more surprises.  Beta 2 has not been tested with this build, we do not intend to support it.

VistaDB 3 and 4 side by side in Visual Studio 2008

There is a conflict that impacts Visual Studio 2008 side by side of our two data sources.  Once VistaDB 4 has been installed Visual Studio 2008 still knows about VistaDB 3.x, but it will not show it for new connections from the Server Explorer (this will impact Strongly Typed Datasets that reference Server Explorer connections). 

In order to fix this you will need to first uninstall VistaDB 4 prior to build 13. 

Then run InstallDesigner for VistaDB 3 from the VistaDB 3 install path like this:

C:\Program Files (x86)\VistaDB 3\VisualStudio\InstallDesigner.exe  ( 32 bit users will not have an x86 in the program files )

After running this command line tool you should see the VistaDB 3 entry in Visual Studio 2008 again. 

Finally, install VistaDB 4 build 13 or higher and you will have two entries present.

Changes and Fixes

There are a number of small changes from user tickets.  Read through the list below if you are looking for something specific.

More...

This build is designated as a development build because we made a change in the optimizer that could affect a lot of applications.  We don't expect it to cause any problems (it fixes one possible error case), and you are free to Go Live with it with your products.  We just ask that you test your code and let us know if there are any problems.

Logging Build

This build is a full logging build.  Logging does not happen automatically against every run of the engine.  You have to turn it on from the Diagnostics namespace, and the Customer Experience tray app has to be running with logging enabled.  By default the only thing we are logging in the CEIP application are Data Builder runs, and the Visual Studio tools (logging exceptions, errors, etc).

To turn on diagnostic logging within your application

At app or unit test startup you would call the startup like this:

VistaDB.Diagnostic.Support.BeginLogging("Starting Test to demo some error"); 

Then during your application shutdown call the EndLogging method:

VistaDB.Diagnostic.Support.EndLogging("Test shutdown complete");

You could also do the begin and end just around a problem area as well.

There are two boolean options on the logging right now to turn on additional information.  By default we only log exceptions and errors in the engine process.  If you are having a problem with an output being incorrect, or some other SQL specific problem you can turn these two options on to log more detailed information.

VistaDB.Diagnostic.Support.IncludeCommandSQL = true;
VistaDB.Diagnostic.Support.IncludeDataReaderRows = true;

The IncludeCommandSQL includes each SQL command that is executed and the parameters passed as a part of the query.
The IncludeDataRows will log each row returned to the command (NOT recommended unless REALLY necessary to see a problem since these rows can get quite large).

Issues and Fixes

Changed the optimizer code to be a little more deliberate in its choice of indexes.  There was an error case where a compound index containing two columns also had a duplicate index covering the first column of the compound index.

More...

Happy New Year!

This will probably be the last build of the 4.0 line as we are almost ready to start the beta testing for 4.1.

Errors and Exception Handling

Changed how the Error dialog displays exceptions.  Many exceptions include a Data dictionary collection of Key/Value pairs with additional information about the exception.  This is present even on a DbException object.  We do fill these out with helpful information in many cases, but the Data Builder dialog was not showing the Data dictionary.  You can trap this in your code and walk the dictionary also using the code below.

   1:  private string GetAdditionalData(Exception ex)

   2:  {

   3:      StringBuilder sb = new StringBuilder(); 

   4:   

   5:      foreach (DictionaryEntry de in ex.Data)

   6:      {

   7:          sb.Append(de.Key);

   8:          sb.Append(" : ");

   9:          sb.Append(de.Value);

  10:          sb.Append(Environment.NewLine);

  11:      } 

  12:   

  13:      return sb.ToString();

  14:  } 

The custom error box we provide has been updated to show this information to the user.

TOP used with variables

Fixed issue where TOP could not be used with a variable dynamically allocated within a SQL Script. 

   1:  declare @howmany as integer; 

   2:  set @howmany = 30; 

   3:  select top(@howmany) from table; 

This now works as expected.

Mono 2.6 now supported

Mono support issue with an invalid IL Code being inserted through our obfuscator now appear to be working.  We have only tested this under Mono 2.6 as the previous production build of Mono had a bug in their implementation of the Microsoft License class.  This has been fixed by the Mono team in the current branch of their code repository, but I am not aware any plans to release it to the prior 2.4 branch. 

As always we recommend you test your application on your target runtime.  Mono is not something we do special coding scenarios around, if there are bugs in the implementation they have to be fixed by the Mono team.  We develop and test on Windows, any compatibility issues should be brought to the attention of the Mono team.

More...