Could you achieve the same results with triggers on rdb$relations and/or
rdb$fields? (Yes, you can put
user-defined triggers on system tables -- you have to be careful to preserve
them around backup/restore,
but they function just fine)


-----Original Message-----
From: Louis van Alphen [mailto:lja@...]
Sent: Thursday, June 08, 2000 3:12 AM
To: IB-Architect@egroups.com
Subject: [IB-Architect] Re: A few more suggestions


David Schnepper wrote:

>Thanks for the details of your application -- I see why you added
>customization features.

>Now, another question -- what is the problem with having the schema
>modifications made by a client-side tool
>(like you do currently) -- eg: why does this need to be in SP ?

The engine creates a lot of extra tables that the user doesn't know about.
For example, one of our column types is a history type, regardless of the
actual datatype of the column. This enables all the changes in the column
value to be preserved with a date stamp. The SET SP that updates the
history column, but also inserts the new value in the history table.

>From this you can see that there is a lot of integrity to be maintained and

it is possible that another programmer may screw things up (if he writes a
client to fiddle with the schema).

If all this is encapsulated by SPs, it is a cleaner solution.

Louis van ALphen







_____

<http://click.egroups.com/1/3373/4/_/830676/_/960459608/>
<http://adimg.egroups.com/img/3373/4/_/830676/_/960459608/>

_____

To unsubscribe from this group, send an email to:
IB-Architect-unsubscribe@onelist.com






[Non-text portions of this message have been removed]