Alexandre Benson Smith wrote:

> The Wogster wrote:
>
>>Seems to be more of a mindset issue, then a database issue, if a
>>customer modifies the database (or hires a independant consultant, who
>>modifies it), and this causes a service call, then the customer should
>>have to pay for the service call, and then deal with the consultant
>>about restitution.
>>
>>It's not hard to, run a comparison tool, to see that a database has an
>>improper modification to it, which means that the customer will be
>>billed for the service call, of fixing it. You can store a revision
>>code within the database to know which revision to compare it to.
>>
>>W
>>
>>
>
> Hi,
>
> I think his main problem is about data changing not metadata changing,
> any way, a good place for a log/audit facility, to track who modifies
> what, when...
>
> An easy way to find the culprit
>

Disabling Sysdba doesn't prevent you from changing the actual data, just
the metadata. Actual data is easier to prevent, by writing all of the
business rules into the database. If there are places where often other
software is linked to the your software, these could be documented, so
that they are done properly, rather then allowing the consultant to try
and figure it out. A consultants manual could be made available for
consultants to purchase that provides this information.

W