PL/SQL Developer insists on either rowid or for update to allow editing data in a grid. While this makes sense for conventional sql, it is not necessarily a valid requirement for views with Instead of trigger logic that handles the inserts. Unfortunately, there doesn't seem to be an obvious way to get around the above requirements. Does anyone have any suggestions?
Edit Grid with 'Instead of' trigger on view
- Thread starter Cal Gordy
- Start date
If the view does not return a rowid then the data can currently not be edited in the result set of the SQL Window. The only workaround is to execute the inserts manually.
It's on the to-do list.
whip
Member²
Identifying the primary key columns is not enough since you are allowed to update these columns as well and also you need to be able to update a table with no primary key defined.
On the other hand, you don't need an instead of trigger to update or insert into a view. The key concept is: key preserved tables. The view user_updatable_columns shows which columns can be updated in a given object.
Tom
On the other hand, you don't need an instead of trigger to update or insert into a view. The key concept is: key preserved tables. The view user_updatable_columns shows which columns can be updated in a given object.
Tom
Sorry, but key preserved tables and which columns can be updated are out the window with instead of triggers.
Instead of triggers allow us to do what we want, regardless of the normal Oracle rules.
We have use of constructs that involve recursions and many to many relationships. Rather than put all the work on custom client code to handle inserts, we prefer to create 'flattened' business views that use server side programmatic logic to do the inserts and updates as appropriate for the business logic. This enables a broader audience to consume the underlying structures - not just a specialized few with a deep understanding of the architecture.
Instead of triggers allow us to do what we want, regardless of the normal Oracle rules.
We have use of constructs that involve recursions and many to many relationships. Rather than put all the work on custom client code to handle inserts, we prefer to create 'flattened' business views that use server side programmatic logic to do the inserts and updates as appropriate for the business logic. This enables a broader audience to consume the underlying structures - not just a specialized few with a deep understanding of the architecture.
