At 09:08 PM 18/08/2005 +0000, you wrote:

>Hi,
>we have just completed our database design,and stored procedures
>also.Now,there were some issues...some columns datatypee was required
>to be changed..but Firebird is not allowing it as it says there are
>dependencies due to stored procedures...so we have to drop all those
>stored procedures..

The "R" in "RDBMS" stands for "relational" in "Relational Database
Management System". If an RDBMS is implemented soundly, the "Management"
will provide systemic support for all dependencies in databases. This
includes preventing anyone from making changes that will break dependencies.

>Our database team is worried it might become
>difficult to maintain changes..to database and stored procedures..are
>their some ways to handle such scenarios?

Definitely. Database teams need to follow effective organisational
practices. The fact that the discipline of database system integrity has
your team worried seems to indicate that it has a need to address change
control.

>P.S because of such problems..I dont like SP's...dynamicSQL using an
>ORM tool is the way to go..

Statements like this throw me into despair. ORM tools are handy, but they
will never circumvent problems that arise from an inconsistent, unstable
design and poor object management practice. One of their worse aspects is
that they allow anyone to be the SYSDBA. This is antithetical to handling
the scenarios that have got your database team worried.

One of the prime objects of a database management system is to enable the
abstraction of business rules so that they are enforced by the db system,
independently of whatever application code is thrown at it. There *are*
well-recognised ways to achieve this externally, through solid design and
careful layering of application code in a 3+n tier architecture, with
centurions armed and ready at the gate.

In 2-tier client/server it is risky business at best to rely on client code
to implement rules.

./heLen