What's New in This Release:

· Exception after dropping objects and automatic one-side rescan. When you script DROPs for all objects in a category (e.g. all procedures) then apply the script to the right-hand database, and the Diff is configured to auto-refresh schema after running a script, the Diff would crash. This happened because the Diff only reloaded the right-side (changed) schema and some references to the deleted objects remained in the other one. Fixed: now the Diff properly cleans up its internal links before each comparison.
· Exception reading FOREIGN KEYs (rare). There appeared to exist a rare situation when the Diff would not correctly read from the database the referenced (target) table for a FOREIGN KEY. That would result in an "Access violation" exception while comparing or later displaying the schema. Although we were unable to reproduce the situation or fully understand how it could happen, additional checks have been added to the schema reader to report and discard any "incomplete" FKs before they are added to the in-memory schema model. We'd be very much interested to see examples of such incomplete FKs and the relevant SQL scripts.
· Exception reading indexes on SQL 2005 (rare). Each UNIQUE and PRIMARY KEY constraint in MS SQL has its underlying index. The server keeps records for the constraint itself and for its index in separate system tables. The two are associated by name and the server normally keeps both names in sync even when either constraint or index is being renamed. However, it seems to happen sometimes that a PK name gets upper-cased on the server whereas its corresponding index name remains as originally entered. When that happened, the Diff would fail to associate an index with the PK, causing an "Access violation" error. This only affected reading indexes from MSSQL2005 servers. The only way we were able to reproduce the problem was by manually changing one of the names in [sysobjects] (under SQL 2000), then re-attaching the database to a SQL 2005 server. Since several users have reported the problem, it is likely that such inconsistency in the system tables was caused by some SQL 2000 database management tool which directly modified the system tables before the database was transferred to SQL2005. In this version, the schema reader has been modified to properly handle such situations.... [ read full changelog ]