I just wanted to take a moment to let everyone in the community know about the hold up of the release for 3.4. We had a trusted partner report a concern with Build 64. It turned out to be a change in behavior of the engine from 3.3 that we did on purpose, but it had a larger impact than we originally considered.

The problem

The basics of the problem were a change in the bahvior of the "Use Default Value in Updates" feature of VistaDB. This is a non-standard feature that we offer, but SQL Server does not. We were going to alter the way this worked on SQL code to be inline with SQL Server. Bad idea, or at least one we can't make mid life cycle for the 3.x line.

Decision to hold release

I made the decision to hold the release because I wanted to make sure we hadn't made any other assumptive changes like this anywhere else. There were none that we could find. If you run into one let us know and we will correct it, document it, and get out the word to everyone.

SQL Server Compliance

We really want to be as compliant with SQL Server as we can within our design goals. It makes life for you as the developer a lot easier. We don't want to lock you in to VistaDB (or any other database for that matter). Your ability to move to SQL Server when you feel it is appropriate should be a decision you make as a business based on your target. Having to make those decisions based upon what your app supports early in the life cycle is usually a bad idea. You will end up with business situations where you need more or less than VistaDB can offer. Giving you the ability to move late in your cycle is one of our goals.

How can you avoid vendor lock?

As a result of this specific issue we are going to take a good hard look at each feature we support that SQL Server does not, and document them. Our goal is not to show what we can do and they can't. Our goal is to give you the information you need to avoid those vendor specific calls or features where they exist.

Syntax we don't support

On the other side of the equation we need to do a better job of showing and documenting SQL Server syntax that we don't support and how you can alter it to work with VistaDB. In some cases like the one above you can substitute one feature for another. SQL Server constraints would allow you to get the same functionality as VistaDB, but it would be a more complex operation.

Release Date?

I expect that we will release 3.4 as stable this week. There are a few more things I want to review before the release. I think we are at our stable code base now, I just want to review some of the customer experiences and user upgrade stories.

3.4 is a pretty big release for us in terms of stability and code maturity. We have a number of large announcements coming over the next few weeks that are very exciting for us, and for you as a VistaDB partner. We know that you could choose any database to fill most data storage needs. We want to show you that partnering with VistaDB is more than just about the engine. It is about freedom of choice, design and deployment that no one else can match.

Thanks

Thanks to all of the VistaDB Team who worked so hard on this release. We have a very talented group who have come up to speed quickly on very complex issues. Thanks for all the long hours.

Thank you to all VistaDB customers who downloaded the beta (over 500 of you did) and took the time to test it in your applications. We got some extremely valuable feedback, we couldn't implement every suggestion or request for this release; but we will keep the tickets open for tracking. We know it is an effort for each and every one of you to help us test.