As was discussed in the previous blog post about VistaDB 3.6 we are now ready to being Alpha testing.
Why Alpha?
This is a new installer. There could be problems with the install process and I want to work them out quickly. I expect to have a few releases of 3.6 during the Alpha stage before we are ready for Beta.
There are a lot of internal engine changes. We have 3 known bugs we are still working right now, but we want to get others started testing as well to make sure we didn’t break anything with existing apps.
What is in this release?
New Tarma based installer. I am planning to do another post about our switch to Tarma, but things have gone very smooth so far. I am quite pleased with the performance and options of the installer. Their support has also been fantastic and very helpful.
The sample databases are now copied to the shared public folder of users. Shared Documents\VistaDB\Databases and Scripts are now included. This is to make it easier to use the demos on a UAC enabled machine without requiring Admin rights. The blank database template (blank.vdb3) is also copied there now. When you right click on a folder and add a new database that blank.vdb3 is the file copied. This allows you to setup defaults you always use (page size, locale, etc) and get them when a new database is built.
Data Migration Wizard is NOT included yet because we are making changes to the interface and functions. The older DMW will be made available as a separate download for users who need VistaDB 2 migration with instructions on how to use it.
Samples are also not included other than the NUnit test project. Samples are being restructured and will be ready before the final release of 3.6.
Release Notes
VistaDB 3.6 ALPHA
Build #85, 06/19/2009
DISCLAIMER: This should be considered a pre-release version of VistaDB and as such should not be considered stable or safe (or deployed to end users). There may be issues within the code we have not uncovered yet.
Always make backups of your data. The file format has not changed and all current applications should continue to run. We have made some interface changes, but they are additive - nothing has been removed.
NOTES
AssemblyVersion changes - We are changing the assembly versioning to now just include Major.Minor. This means that your major.minor will be what is visible in the GAC, and will avoid binding issues for each new build. Only new minor builds will have to be rebound. I also greatly simplified the App and Web.config scenarios.
AssemblyVersion - 3.6.0.0
FileVersion - 3.6.85.1 MAJOR.MINOR.BUILD.EDITION
FileVersion is not seen in the GAC, but is visible if you right click a file and go to properties - Details. You can see the File Version on that dialog.
This should just mean that it is easier to bind against VistaDB. Especially users who build lots of CLR Procs will find that you only have to rebuild them when a minor version increments rather than for each build.
ISSUES AND FIXES
InvalidFunction exception when exec call to StoredProc and unopened connection - Changed the Preparser to look for this situation and tell you the database connection must be opened first. The engine CAN exec some things without having an open connection (Create database). But when the list of stored procs is attempted to be loaded it fails because the connection is not open.
RAISERROR syntax has been added to the parser for TSQL Procs. Note the spelling. This is a bit strange to me, but it is how SQL Server spells it.
You can now call it like this:
RAISERROR ( {IntID|StringMessage|Variable} ,Severity, State )
RAISERROR ( 'An error happened', 1, 1 )
Severity and State have no meaning in VistaDB, they are present for compatibility reasons.
Additional arguments to the call are not supported at this time.
PRINT syntax has been added.
PRINT output is not returned within results to queries. It is a separate side-channel of information sent back through the VistaDBConnection.PrintNotification event.
ConnectionString new option:
Transaction Mode=[on|off|ignore]
On is the default and transactions operate normally
Off means transactions are not to be attempted, creating one will throw an error
Ignore means that attempts to create transactions should be ignored. This is useful for people using tools that generate transactions through SQL and are unable to turn them off in the tool (ORMs frequently do this)
This option has also been added to VistaDBConnectionStringBuilder as the TransactionMode read only property.
VistaDBDataReader.Read() on a non-result returning command would throw an error due to a missing result set. It will not return false since no results are available.
OTHER NON TICKETED ITEMS
A lot of internal structure updates from our 4.x dev work. Things of particular note are the way that we match indexes eligible for inclusion with the optimizer. We are still using the same indexes (only those present), but this lays the foundation for us to build temporary or internal indexes for optimization. We have also removed cross object dependencies internally on some objects to avoid pinning them in memory longer than required.
Most of these internal changes should have little effect on runtime (ok, maybe a slightly smaller footprint in some classes).
We have simplified the code paths and internal classes in many cases to avoid virtual calls and removed them on internal classes where possible so the JIT optimizer may inline more of these functions as well.
Databases with large numbers of stored procedures (25+) will load much faster now due to internal changes made in the load structures and how we cache the data from the disk. We don't anticipate any problems, but we want people to test this code in their apps as well.
Some interfaces have changed as a result of code changes. And a few obsolete methods have been removed from the public interfaces. As an example HasDataSetResult was flagged as obsolete since 3.2 and has now been removed.
You may also notice some Intellisense cleanup as we have been attempting to go through the public classes and flag designer attributes as non browsable to avoid intellisense confusion of how to use objects. Many of the ADO classes have Design Time properties that are not intended for end users, only Visual Studio.
VistaDBException now inherits off of System.Data.Common.DbException instead of straight off of System.Exception. This allows for the generic user of the Provider Factories to trap DB errors and retrieve the provider error code without having to cast into the VistaDB namespace.
The DATE() function has been deprecated since it was not compatible with SQL Server syntax and caused quite a bit of confusion for users.
BuildVIndex has been removed from the Interface. It has been deprecated for quite some time. BuildIndex is the correct function to call.
Safety Warning
As always make backups of your application databases just in case. We are using this engine with our systems, but we ask that you not publish this edition to users other than if you have your own testers who understand the risks.
Subscribe