At 07:33 PM 20/08/2005 +0000, you wrote:

>Hi Helen,
>I completely understand what yu r saying..change control..how to
>implement it? Can yu pls give some suggestions?Best practices?

Google this: Programming +"Change control". It's a pet topic of thousands!

Recommended reading: "Code Complete" (Second Edition) by Steve McConnell
is inspirational and "Agile Database Techniques" by Scott Ambler is both
smart and practical for getting your head around the issues you need to
consider.

Tattoo this on your forehead: "One SYSDBA to rule them all". There should
be only one.

Firebird is particularly good for team development, since each DBA and
programmer can easily have a local server to experiment and test with, that
is separate from and updated regularly from the SYSDBA-controlled
development version.

Peer review is (IMO) at least as essential in database development as in
application development, if not more so. Wild, unreviewed implementation
in databases will have greater damage potential than dirty application code.

In my (well-known!) view, one should be maintaining ones schema scripts
from Day Zero Minus N of the design implementation. Schema scripts should
be under total version control. Similarly for data dictionaries and any
other formal mechanisms used by the team to assist with and document
development.

Also well known to victims of my conference talks is my strong support for
designing requirements-based tests for everything *before* you implement
*anything* - database, applications, ANYTHING. Both the test code and the
results also need to be under strict version control.

You might like to start a thread on this topic in Firebird-general. It
could evolve into something of great interest. However, it's not a topic
to explore in depth in the support list without obstructing the coal-face.

./heLen