Recently, ZDNet published an article on the reasons for application failure. One of the main reasons mentioned in the article is Data Corruption. The article notes that developers have unfettered and uncoordinated access to database values which can cause a ripple effect on incorrect reports, bills and inventory problems. This seems to be a common problem for development teams and DBAs.

dbMaestro TeamWork can help address these issues by applying standard SCM methodology to the structure and data-content of the database. TeamWork can apply locks to schema and values in the database in order to ensure that any modification is performed under the project’s guidelines for change. TeamWork ensures that a developer must first check-out the data in a table before modifying it. This provides a number of advantages:

1. Ensure that only one developer can make changes to an object at any given time;
2. Data or schema cannot be changed without adhering to change-control procedures;
3. A complete audit-trail is maintained (you can track what change was made by which developer, and when);
4. All changes are kept in a versioned time-line which allows a rollback to any previous (and known good) version of data or schema.

TeamWork can assist development teams and DBAs by preventing the introduction of costly data-corruption into the database development process and facilitating recovery from such situations.

Three-way analysis & merge are very different to traditional compare and sync tools, both from a technical point of view, and from a practical point of view.

Using a traditional comparison tool – we compare A to B, performing a two-way-compare (development to testing for instance).  Comparing A to B will result in very shallow results.  For example, “A is different than B”, or “object X is in A and not in B.”   There is no way of knowing if either A or B has changed, or if X was added in A or deleted from B.  As a result, you have to start looking for additional information, go ask the developers, the DBAs, etc.

This is incomplete information, and of course, after you investigate and understand the reason for change, and decide what is the safest thing to do – relying on compare and sync tools will only enable you to either deploy A or deploy B, nothing in-between!

Using dbMaestro TeamWork will get you a deep examination of changes, leveraged by a three-way-analysis:

All changes are analyzed and examined with relevance to previous versions or a reference environment (this is an A vs. B vs. C analysis, hence a three-way-compare).  When deploying changes from development to integration, TeamWork will also analyze the previous revisions of the relevant database objects, and return with very informative and final results.  If A is different than B, you will know if A changed or B changed, because you know what their previous state was.  The result is a perfect understanding of changes that enables TeamWork to recommend the appropriate action.

If an object has changed in development – TeamWork will suggest you deploy it to integration.  However, if another team has updated the integration environment, and it is different to development, TeamWork knows it will cause damage to overwrite integration, and will recommend you ignore the change, or take it back to development.  All of this comes with complete documentation of each change, and the reasons it was introduced.

But the good stuff doesn’t end there – TeamWork will also deal with conflicts: if a change was introduced to both A and B (typical when more than one team develops for the same database), an automatic conflict resolving engine will come into play.  Based on all the analyzed information, TeamWork will suggest combined code, taking all changes into consideration and merging changes from both development and integration into a single piece of code.

The TeamWork three-way-analysis and automatic conflict code resolver is a unique offering for the database world.