Gibraltar VistaDB 5.1.0.1385
Gibraltar VistaDB 5.1.0.1385 | 31 Mb
VistaDB is the only .Net embedded database that allows you to Xcopy a single DLL for both 32 and 64 bit runtime support. Want ClickOnce deployment for your .Net application? VistaDB requires zero config on the client. No more worries about COM deployment for the database engine! Even our database files are built for ease of deployment - a single database file with no external logs or complex permissions..Net Database Basics
If a relational database doesn't have advanced features like updatable SQL Views, true referential integrity, cascading updates / deletes, table value params, T-SQL stored procedures, CLR Triggers, and CLR stored procs then why would you bother? Database engines that only provide basic ADO.NET features are a waste of your time. VistaDB is the most advanced embedded SQL desktop database engine in the world. We built VistaDB from the ground up to be a managed database engine, this is not some unmananged C++ database with a .Net wrapper!
Support VistaDB and SQL Server from the same executable?
Do you wish you could build a single executable that supported both SQL Server for multi user and another database on the desktop? We know how hard it is to build applications that support both desktop and client server from a single executable. VistaDB syntax contains the most commonly used features from SQL Server. All of our syntax will scale up to SQL Server. This means you can use one codebase in your product and run it against SQL Server and VistaDB. VistaDB fully supports the ADO.NET Provider Factory model. This allows you to dynamically load the database engine at runtime based upon application preferences. Many companies use VistaDB on the desktop and SQL Server for larger deployments. It is not the easiest way to write database code, and there is much less documenation around to explain how to do some things in Visual Studio. But if you take the time using Provider Factories can be a powerful runtime feature for your application.
.Net Database Admin Tools?
Some embedded databases give you an engine and nothing to edit or maintain the actual database. You usually have to purchase a third party DBA tool, build you own, or tell users to go download the large bulky tool from the vendor.
ew Features in This Release
Storage Layer Optimizations
The internal storage engine used for deserializing and serializing rows for data tables and indexes has been revised to eliminate the need to process rows in the same page that aren't used. The net effect is a doubling in performance of single-row writes and inserts and up to a seven fold improvement in index lookup performance. For more details see VistaDB 5.1 Dramatically Speeds Up, Well, Everything on our blog
Query Optimizer Improvements
The query optimizer in VistaDB 4 could only apply the first column of each index in optimizing a query. The query optimizer in 5.0 could apply a multi-column index and be far more efficient when applicable constraints are ANDed together but had to choose between that approach or an approach similar to the older single-column optimization and could not be easily predicted by users. The query optimizer in 5.1 will seek multiple indexes to cover constraints and can use multiple columns from any index for applicable constraints producing both the improved efficiency of multi-column indexes—particularly when JOINing on multi-column keys—and the generality of combining filters from multiple available indexes to cover available constraints.
Query Optimizer Performs Estimation
The query optimizer now estimates the work and effectiveness of applying each constraint and index. It is able to reduce the work needed to mark a filter for a constraint which would keep more than half of the available rows of a table by estimating when marking the excluded rows would take less time than the included ones. It can then compute the actual filters for each applied index by priority based on least work and greatest effectiveness (fewest rows included), and it can end further (wasteful) optimization when the next-most-effective filter would take more work than simply checking each row in the already-filtered set.
Query Optimizer Migrates Constraints
SQL allows for constraints (WHERE clauses and Join predicates) to be specified any point after the related tables are defined. This can be a more clear TSQL syntax in some scenarios. VistaDB 5 processes the constraint exactly where it was mentioned even if that was much later in the query than it could be applied. VistaDB 4 would consolidate all JOIN and WHERE constraints into one combined clause which produced incorrect results with some OUTER JOIN scenarios. Now, VistaDB will apply constraints from any JOIN or WHERE clause to attempt to optimize the table each constraint applies to.
Execution Engine Runs Correlated Sub-queries More Efficiently
In the past, VistaDB has treated each sub-query independently. Correlated sub-queries had to be re-executed for each row of the parent query even when the differences were only in non-correlated tables not referenced in the sub-query. While this produced accurate results, the extra work could significantly degrade performance—particularly for some O/RM tools which rely on sub-queries. VistaDB will now re-execute a correlated sub-query only when a correlated table referenced from the parent query is advanced to a new row… although currently without regard for whether the referenced column(s) actually have different values in the new table row.
Upgrading to This Release
New Data Format
To implement the storage engine optimizations listed above it was necessary to change the underlying storage format used to serialize some data types, so version 5.1 has a new database format version. To preserve compatibility, VistaDB 5.1 (and later 5.x versions) can access and write to a 5.0 database and will leave it in that format unless a pack is performed. This will leave the database accessible to 5.0 versions, but it will not have the storage performance improvements.
As always, to upgrade to the latest data format just perform a pack on the database using the 5.1 (or later) engine in order to unlock the improved performance of the new storage layer. Once a 5.1 or later engine has packed and upgraded a database it will no longer be accessible to 5.0 versions . Keeping a backup copy of the database is recommended when performing a pack (and regular backups in general practice) but may be even more advisable when upgrading to a new format since there is no way for applications to reverse the update back to the older format.
Any new (or migrated) database created by a VistaDB 5.1 (or later) engine will use the latest storage format and have the improved storage layer performance but will not be accessible to 5.0 or older versions of VistaDB.
New Assembly Version
Because the file format has changed and the VistaDB engine can be installed in the Global Assembly Cache (GAC) the assembly version has been changed . This ensures that an application built against VistaDB 5.0 won't accidentally start using the VistaDB 5.1 engine and potentially upgrade its database to a format that the engine it shipped with can't read. While the number of scenarios where this type of problem could occur are few, the consequences would be confusing and difficult to troubleshoot so the decision was made to prevent them.
To accommodate this assembly version change the assembly versions of the VistaDB Entity Framework providers and other assemblies that reference the engine have been updated as well. If your references to these assemblies are marked to be version specific you will get a warning when you recompile your application that it can't find the necessary assemblies. Re-create the references or mark the references as not being version specific to resolve the issue.
Storage Layer Optimizations
The internal storage engine used for deserializing and serializing rows for data tables and indexes has been revised to eliminate the need to process rows in the same page that aren't used. The net effect is a doubling in performance of single-row writes and inserts and up to a seven fold improvement in index lookup performance. For more details see VistaDB 5.1 Dramatically Speeds Up, Well, Everything on our blog
Query Optimizer Improvements
The query optimizer in VistaDB 4 could only apply the first column of each index in optimizing a query. The query optimizer in 5.0 could apply a multi-column index and be far more efficient when applicable constraints are ANDed together but had to choose between that approach or an approach similar to the older single-column optimization and could not be easily predicted by users. The query optimizer in 5.1 will seek multiple indexes to cover constraints and can use multiple columns from any index for applicable constraints producing both the improved efficiency of multi-column indexes—particularly when JOINing on multi-column keys—and the generality of combining filters from multiple available indexes to cover available constraints.
Query Optimizer Performs Estimation
The query optimizer now estimates the work and effectiveness of applying each constraint and index. It is able to reduce the work needed to mark a filter for a constraint which would keep more than half of the available rows of a table by estimating when marking the excluded rows would take less time than the included ones. It can then compute the actual filters for each applied index by priority based on least work and greatest effectiveness (fewest rows included), and it can end further (wasteful) optimization when the next-most-effective filter would take more work than simply checking each row in the already-filtered set.
Query Optimizer Migrates Constraints
SQL allows for constraints (WHERE clauses and Join predicates) to be specified any point after the related tables are defined. This can be a more clear TSQL syntax in some scenarios. VistaDB 5 processes the constraint exactly where it was mentioned even if that was much later in the query than it could be applied. VistaDB 4 would consolidate all JOIN and WHERE constraints into one combined clause which produced incorrect results with some OUTER JOIN scenarios. Now, VistaDB will apply constraints from any JOIN or WHERE clause to attempt to optimize the table each constraint applies to.
Execution Engine Runs Correlated Sub-queries More Efficiently
In the past, VistaDB has treated each sub-query independently. Correlated sub-queries had to be re-executed for each row of the parent query even when the differences were only in non-correlated tables not referenced in the sub-query. While this produced accurate results, the extra work could significantly degrade performance—particularly for some O/RM tools which rely on sub-queries. VistaDB will now re-execute a correlated sub-query only when a correlated table referenced from the parent query is advanced to a new row… although currently without regard for whether the referenced column(s) actually have different values in the new table row.
Upgrading to This Release
New Data Format
To implement the storage engine optimizations listed above it was necessary to change the underlying storage format used to serialize some data types, so version 5.1 has a new database format version. To preserve compatibility, VistaDB 5.1 (and later 5.x versions) can access and write to a 5.0 database and will leave it in that format unless a pack is performed. This will leave the database accessible to 5.0 versions, but it will not have the storage performance improvements.
As always, to upgrade to the latest data format just perform a pack on the database using the 5.1 (or later) engine in order to unlock the improved performance of the new storage layer. Once a 5.1 or later engine has packed and upgraded a database it will no longer be accessible to 5.0 versions . Keeping a backup copy of the database is recommended when performing a pack (and regular backups in general practice) but may be even more advisable when upgrading to a new format since there is no way for applications to reverse the update back to the older format.
Any new (or migrated) database created by a VistaDB 5.1 (or later) engine will use the latest storage format and have the improved storage layer performance but will not be accessible to 5.0 or older versions of VistaDB.
New Assembly Version
Because the file format has changed and the VistaDB engine can be installed in the Global Assembly Cache (GAC) the assembly version has been changed . This ensures that an application built against VistaDB 5.0 won't accidentally start using the VistaDB 5.1 engine and potentially upgrade its database to a format that the engine it shipped with can't read. While the number of scenarios where this type of problem could occur are few, the consequences would be confusing and difficult to troubleshoot so the decision was made to prevent them.
To accommodate this assembly version change the assembly versions of the VistaDB Entity Framework providers and other assemblies that reference the engine have been updated as well. If your references to these assemblies are marked to be version specific you will get a warning when you recompile your application that it can't find the necessary assemblies. Re-create the references or mark the references as not being version specific to resolve the issue.
[/b]
[b]
Only for V.I.P Warning! You are not allowed to view this text.