Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

WHEN-REMOVE-RECORD -> Loop thru block and update. 1

Status
Not open for further replies.

Petemush

Technical User
Jun 21, 2002
255
GB
Hi,

I'm using Oracle Forms 6i.

I have a form with 3 blocks on it. Like so:

Code:
 _____________
|   BLOCK 1   |         
|_____________|
|BLOCK2|BLOCK3|
|______|______|

In block 3 I have a text item which repeats down indefinitely with a scrollbar to the right.

Whenever I insert a new row into Block 3, I check the data and if it's a certain piece of data I update an item in Block 1 and then disable that same Block 1 item using SET_ITEM_PROPERTY.

What I want to do is, everytime I delete a row from block 3, I need to check whether the data deleted was the data that caused Block 1 to be updated. If that data was deleted I would like to reenable the item in Block 1.

The best way I thought I could do this is use the WHEN-REMOVE-RECORD trigger and everytime something is deleted from Block 3, to loop thru the rows left in that block and check whether the data I'm looking for still exists.

How do I do this? I can't seem to get GO_ITEM, PREVIOUS_RECORD, NEXT_ITEM or any other restricted procedure to work in the WHEN-REMOVE-RECORD trigger.

Also, what level should I place this trigger on, I had it at item level but I think that's wrong and it should be at block level?

Any help much appreciated,

Cheers,

Pete
 
I would create a record group that is populated on query. The group would contain the data yuo need to check for.

As you insert or delete rows you can use :SYSTEM.TRIGGER_RECORD to determine what number record in the record group to create or delete.

When you delete a record, you can use GET_GROUP_RECORD_NUMBER to determine if a record still exists before setting the properties in block1. Using a group this way removes the need to use GO_BLOCK etc., which as you correctly say is a restricted procedure.
 
Hi Lewis,

Thanks for that, it does seem to be the way forward.

The problem now is that if you delete a row from the block, any rows with a greater TRIGGER_RECORD than the row just deleted, have their TRIGGER_RECORDS decreased by one.

So if there were two rows that I had recorded in the record group and I deleted the first one from the block, then it would delete from the record group fine but when I come to delete the second row from the block, it's trigger record would be decreased and therefore wouldn't be deleted from the record group.
 
The way record groups work is that the record numbers are shifted when a row is deleted from it.

So if you have a record group with 2 rows and you delete row 1, the row that was in position 2 now moves to position 1.

If you are deleting more than one record at once, you may need to look up the values of the row you want to delete first by using GET_GROUP_RECORD_NUMBER using the value of the row you are deleting as the lookup value. Then simply delete the row number returned by the call.
 
Sorry, what I meant was that in the record group, I was recording the row id whenever you insert a row with certain data.

Like you say, since the row id's change, this isn't a viable way of doing it. I've pretty much done what you've suggested and started recording the data and matching against that and it's all working fine.

I'm guessing I'll have to make sure there's a refresh of the record group on the blocks post query. Since it's a base table block I've made the record group based on a query from that table.

Cheers for your help!

Pete
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top