Browse Prior Art Database

COMPARISON PROGRAM FOR DATABASE APPLICATIONS

IP.com Disclosure Number: IPCOM000008869D
Original Publication Date: 1998-Sep-01
Included in the Prior Art Database: 2002-Jul-19
Document File: 2 page(s) / 107K

Publishing Venue

Motorola

Related People

David Levin: AUTHOR [+2]

Abstract

Client/Server applications are normally designed with an initial schema architecture and then is implemented within a database application (eg. Oracle, SQL Server, Access, Paradox, Interbase). As features are developed and new releases are created, the schema goes through numerous changes. These types of applications are typically developed by a group of 7-10 engineers working on different features per a release. To keep track of the changes being made to the schema, the database is version controlled using clearcase. Before an engineer could modify the schema archi- tecture, the engineer needed approval by a change control board (CCB). Changes to the data that was stored within the schema was not reviewed by the CCB, but was reviewed during the engineer's devel- opment reviews.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 50% of the total text.

Page 1 of 2

0 M

MOTOROLA Technical Developments

COMPARISON PROGRAM FOR DATABASE APPLICATIONS

by David Levin and Anne Rasmussen

BACKGROUND

   Client/Server applications are normally designed with an initial schema architecture and then is implemented within a database application (eg. Oracle, SQL Server, Access, Paradox, Interbase). As features are developed and new releases are created, the schema goes through numerous changes. These types of applications are typically developed by a group of 7-10 engineers working on different features per a release. To keep track of the changes being made to the schema, the database is version controlled using clearcase. Before an engineer could modify the schema archi- tecture, the engineer needed approval by a change control board (CCB). Changes to the data that was stored within the schema was not reviewed by the CCB, but was reviewed during the engineer's devel- opment reviews.

  Normally, when multiple development takes place, the engineer branches the necessary files to develop the feature. However, since the database was a binary file, merging was not possible because there was no means to compare the versions. Hence, branching was not an option.

  Additionally, since database comparisons were unavailable, the only way to determine what changed was relying on the engineers check-in and check-out comments. However, the check-in and check-out comments were not very reliable because they were incomplete or vague. For example, a revi- sion comment could look like "fixed defect CCAar12345", not stating exactly what was changed. Comments were needed to determine :

. where defects were sourced

. what defect fixes were pulled into what releases

. when the schema architecture was changed

. what upgrade database application work needed to be done based on changes made to the schema architecture

. what database version should be used for the lat- est release

. what changes needed to be removed from the database so that it could be released (validations and new development ran in parallel)

PROBLEM

  The engineers would check-in and check-out the database when changes needed to be made. However, when multiple development was taking place and the database was "checked-out" by some- one else, the engineer would copy the "latest" ver- sion of the schema to the PC, update the local copy for testing purposes. When the database...