Re: Data change watch without triggers

stan wrote:

>>Why not? Triggers are there to protect data integrity. What's the reason
>>behind saying that user A is not allowed to "use" triggers? Besides, it is
>>not the _user_ who is using the trigger, but the _database_.

Interesting. What is the business reason/requirement behind this db config check? If auditing, there are better (and more correct) ways to address it than via a custom (and source code less) piece of software.

Or it can be as simple as making the SYS & SYSTEM users secure and removing DBA & others privs from users who should not have them in the first place.

> I need that B know when table in A changed. Than I can write a
> extention for the programm from Oracle. par Example to inform an
> Interface for continues processing

I would ask again what the requirements are behind wanting to know this. If needing to determine "what is new?", the simplest would be to have a datetime stamp on a row (updated via a trigger).

To answer your basic question - is it possible to watch for row changes in a table without the use of a trigger (or without a datetime column or an updateable view or something similar), then IMO the answer is no.

It makes sense to me to use the standard fearures of the database as designed and implemented. A trigger is there to provide a certain type of functionality. So use it for that. Thinking that this should NOT be used to do what it is suppose to do in the first place... that's weird and more than just a tad twisted logic. IMO.

Besides, what is the real problem here? Oracle? Triggers? Or not having the sourcecode of some Pro*C program?

Fix what is broken. Don't mess with that which is not broken. Treat the cause and not the symptom. <insert other catchy and relevant sayings here>

--
Billy