VistaDB 3.3 Build 56
Build #56, 4/13/2008
NOTES
This build is being built with a number of new tools on our end. It should not impact anything in the product (we hope), but I wanted to give everyone a heads up.
Visual Studio Integration SDK (VSIP) - Now using the latest build from last year that includes some new tools and functions.
Visual Studio 2008 SDK Update - Microsoft released a new SDK for VS 2008. Not sure yet how this will impact us. We will read through it and see if it makes sense to build a special plugin for VS 2008 over the current one in VS 2005. I don't know of any reason yet why we would.
DotFuscator 4.3 - New version of dotfuscator with a few new features. We are not using anything more than we always have, but there are some changes in how they work internally. We have done all the regression tests we know how at this point without any problems showing up.
Compiling on my Vista 64 Bit desktop machine. Used to only build on 32 bit XP. Should not change anything in the end result.
Sync Framework V1.0 Runtime ADO.NET V2.0 - confusing I know. You have to be running the latest Sync Framework (1.0 CTP1 REFRESH). Make sure you uninstall and then go kill the c:\programfiles\Microsoft Sync Services\ directory. On all our dev machines the uninstall from CTP to the CTP1 update left files on disk that caused problems later.
Compact Framework 2.0 Service Pack 2 is now being used in the CF versions, along with Windows Mobile 6 Pro SDK (All providers are being tested).
Source Code Subscribers: We are changing to a new Source Control solution right now so some of the headers will appear to include bad data. We will be updating the headers of all files once we get it setup and stable.
Some internal structs have been modified to use generics and thereby along them to be used as strongly typed items rather than generic ones. A few of these small changes have had 3x performance gains within some routines. This work will continue while we prepare for 3.4 release.
ISSUES AND FIXES
#654: Databuilder takes longer and longer to load when more stored procs are added. Fixed
#17: Go keyword should be supported in Databuilder. Implemented - You can now use GO as a separator between SQL instructions in Data Builder.
#478: Insert performance problem - Was actually Data Builder drawing the plan that took time. Added new option to allow you to turn off drawing of the plan.
#650: Databuilder allowed selection of CLR Trigger options with no database loaded - would crash. Fixed
#651: Databuilder cannot pack a database that cannot be opened. Fixed - we now allow you to Pack a database and choose the file if none are open.
#652: Cannot attempt a repair database from the Data Builder. Fixed - Added new Repair database option from Database menu to attempt repair of database files.
OTHER NON TICKETED ITEMS
Bug numbers will seem off the charts in the past few weeks. We had a spam bot start filling out ticketing for bugs. I tried to remove all of them from the system, but because FogBugz sent emails to these spammers (and spammed innocent people probably) many of the emails bounced and Fogbugz built up new tickets for the bounces. What a great example of not designing your system to get hit by spammers and then they take advantage of you. As a result some of the tickets could not be removed due to relational constraints in the database which means we have huge gaps in ticket numbers now.
We have implemented a captcha system in front of the bug ticketing system for now as a short term solution.
The Data Migration Wizard is broken in this build for VDB2 database migration. It will be fixed before next build.
There is a known ALTER COLUMN bug that can lead to a null reference. You should execute ALTER statements with ExecuteScalar() - putting it through a DataReader and calling Read() leads to a null object reference. We have an open ticket on this issue.

Comments
Jason Short on on 4.13.2008 at 1:02 AM
I should also mention that if you see any path that looks like this:
C:\Program Files (x86)\
For a tool or app (Like NUnit) it is due to the new build being performed on a 64 bit Vista machine. All non 64 bit apps get put into that x86 version of the program files path. Our application does too because the setup app is 32 bit and does not tell Vista what we can do correctly.
Just modify any x86 from the path if you get an error.
Hans Nieuwenhuis on on 4.13.2008 at 10:11 PM
Hi Jason,
The CF version of VistaDB is now built using .NET CF 2 SP2. Great!
I'm making an application for Windows Mobile in .NET CF 2 SP2. That means until now I have been using a version of VistaDB which was built for an older version of .NET CF. What does that mean if I run my program in such a situation? Will *my* code use .NET CF 2 SP2 and the VistaDB code an older version of .NET CF? Or will the VistaDB code also automatically use the newer version of the .NET CF?
What kind of advantages can I expect if I use the new VistaDB code (which has been built with .NET CF 2 SP2)? The same advantages as for every application built with the newest .NET CF I assume (faster and using less memory)?
Jason Short on on 4.14.2008 at 12:54 AM
The SP does not have many new features, but a lot of bug fixes. I wanted to list it so users would know to test their applications. Check on the MS site for the complete list of fixes in SP2 (there were a lot). The specific reason for us upgrading was due to a JIT error.