VistaDB Changelog

What's new in VistaDB 3.6 Preview Build 87

• This is a big build for us. We feel this is probably really close to a release for 3.6. We know we have some rough edges to clean up around some things, but we feel the core feature set is present and the options are all falling into place.
• Entity Framework Sneak Peak
• We have not decided if we are going to leave the EF in the 3.6 edition when we release, or if it will continue to be a Preview technology. It all depends on the feedback we get from the community.
• The Entity Framework DLL implements all the commands, but we are not sure about all the various SQL generation strategies in the EF runtime. I am sure there are some LINQ commands that will generate terrible SQL for us, but we need to find those and get them addressed. I wanted to get a profile and stat output for this build, but it didn’t make it in – maybe next one. I think the EF basics should work for just about anything, it just remains to be seen how well it performs on various LINQ commands, and what we can do to improve it.
• The current plan is to test EF for now as a Preview technology and ship it later this year. Is this feature a big enough deal to bump the version to 4.0? We would like to know your feedback. It has been a lot of work to get all of the EF implemented and tested, but hopefully it will show people that VistaDB is quite serious about the future of database technologies. People thought we hadn’t shipped it because we couldn’t do it for some reason. We are just taking a very cautious approach, hopefully that is something you can appreciate from your database vendor.
• GetSchema Changes
• A lot of GetSchema() rework was required to get this to work for this preview. We had the changes in the next gen engine, but I ported them back to the current line. It had some unfortunate side effects on the Data Set designer though. There is a possibility that some strongly typed dataset generations may not work correctly. I fixed all the ones I found, but now it is time for you guys to give it a whirl. So even if you don’t care about EF, please test the DataSet code as well since they now share some schema calls.
• We are attempting to much more closely match the SQL Server GetSchema calls for most of the collections. New samples for GetSchema will be posted on the blog and included in the final setup. Some schema columns names were also changed to match SQL Server (IsLiteralsSupported was not plural before). There were a number of GetSchema changes required for the EF provider as well that also impacted the Strongly Typed Dataset Wizard.
• There could be issues with Stored Procedures in both the EF and DataSet designers. It appears we are using a syntax they don't like for parameters. The newer format is much more flexible and I am quite excited to get it into peoples hands. I know that not a lot of people use the GetSchema calls, but I plan to do a series of blog posts about the changes that might change your mind about how useful they are for getting dynamic data about the database.
• SQL Server 2008 incorrectly returns some of the size fields for type in their GetSchema calls (TinyInt is 3 bytes in size when it is actually only 1). Rather than match their incorrect information we return the correct byte size for all types.
• Dynamically Load .Net 3.5 SP1 Required Assemblies
• And I also wanted to take a minute to publicly thank our own illustrious Mike Swain for his work on extrapolating the EF designer so we could keep the primary engine in .Net 2, but dynamically load the EF Designer (.Net 3.5 SP1) only when needed. We have not tested what happens on 3.5 machines without SP1, etc so I am sure there are edge cases. But the basic theory works incredibly well. It lets us put all our 3.5 SP1 specific code in the VistaDB.EF.dll assembly and not have to maintain two builds of the engine! That is always great news to me! Thanks Mike!
• NOTES
• This build is flagged as a development build. That means all licenses will expire 30 days from the day it was built. 8/16/2009 this build will expire. We plan to have final release before that time so it should not be an issue.
• The Data Migration Wizard is a separate download from the Account Manager. We are planning to rework the way it grabs schema and data, and remove VistaDB 2 support at the same time. See the blog for more information. The download is already up on the site.
• This build has not been tested on machines without .Net 3.5 SP1 - please make sure you have that SP1 installed first. The EF provider requires it and we are not testing to see if it is not present in this preview build.
• ISSUES AND FIXES
• The VistaDBCommand object Cancel function cannot throw an exception because it will cause the Visual Studio designers to not work correctly. The Cancel function has no meaning in VistaDB at the present time, but we have to leave it as a return only function. This was causing DataSets to not generate correctly in the last preview.
• Removed the EXCEPT and INTERSECT commands. They were not implemented correctly and will not be supported right now.
• Corrected a bug in the Membership provider where the use of the lockout window would cause all logins to be successful regardless of password.
• OTHER NON TICKETED ITEMS
• Lots of updates to the Help files. New HOWTO section on Foreign Keys with some examples and explanations of why you might use the various integrity actions.
• The Data Builder now has a splash screen while it is validating the design time license of the machine. The Data Builder cannot be run on a machine without a design time license. The DBA Sample Tool is the only way to get a DBA Type tool you can redistribute.
• Runtime vs. Design Time Licenses
• The way runtimes licenses work in the engine has changed dramatically. All applications built that use VistaDB must include a licensex file now. That means if you have a DAL that is then included in an EXE the EXE must also have the licx file included.
• This includes changes to the Data Builder to only run on a machine with a design time license (developer machine). This build actually enforces the concept that each developer must have a licensed machine through the licenses.licx file. The runtime can still be distributed royalty free, but every executable that uses VistaDB must have a valid licx file at compile time.
• There are new topics in the help file specific to the license system. And a sample licenses.licx file is included in the setup as well.
• Make sure you run the License Manager at the end of setup. It will install your current license for your machine in the proper location to act as a design time license. The same license files are used, we have just incorporated a wrapper around the Ezriz license tool to use the Microsoft License API for design time and runtime components. The location of the design license on your machine is the public shared data folder (C:ProgramDataVistaDB on Windows Vista by default).
• The licenses.licx concept should be familiar to anyone who uses third party components in Visual Studio. It basically binds in a license at compile time to your application to ensure that end users cannot also use the same component at design time. We can't autogenerate the licx file yet (although we want to eventually) because we are not a component you drag to a design surface - that is the only way to get Visual Studio to generate it for you. We are researching this issue.
• We also have some changes coming in the License Manager to automate the process of getting your initial LIC3 file from the servers. They just were not tested in time for this build, next one for sure!
• NUnit / VSTest license?
• I anticipate an early question about how do you license the EXE when you don’t build it. Applications like NUnit and VSTest run your assemblies and need to dynamically load the license, right? Well, not exactly.
• We have added a great way to handle this situation (well, we think it’s great). All you have to do is add an attribute in your AssemblyInfo at compile time to tell the engine to use the Design Time license of the machine for testing with unit runners.
• [assembly: VistaDB.UseVistaDBDesignTimeLicense]
• That’s it. There is a topic for it in the Help file as well. Once you add that attribute to your assembly the design time license for the machine will be used when the assembly is loaded and the license queried. This allows for quick and easy application testing with a minimum of fuss.