hide value from list of value [message #628387] |
Mon, 24 November 2014 13:16 ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
![](http://www.gravatar.com/avatar/043a1274cb670fd010565969fc56603d?s=64&d=mm&r=g) |
hassan08
Messages: 123 Registered: June 2011 Location: egypt
|
Senior Member |
|
|
i have a tabular form and on the form put a button to open list of value
and i want when select value 1 just example
and down to and another record and open list value the value 1 will be hide
and when select value 2 just example
and down to another record and open list value the value 2 will be hide
|
|
|
|
|
|
|
Re: hide value from list of value [message #628422 is a reply to message #628399] |
Tue, 25 November 2014 03:18 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) ![Go to next message Go to next message](/forum/theme/orafaq/images/down.png) |
cookiemonster
Messages: 13937 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
CraigB wrote on Mon, 24 November 2014 21:21
If this is correct, the easiest way would be to commit each row to your table and filter your LOV to exclude those values that are already in your table.
If you don't want to or can't commit between each record, this is still doable, but much harder. It would require you to keep track of all of the selected LOV values and dynamically alter the LOV's record group query to specifically exclude the selected rows.
You should read up on what post does.
|
|
|
|
Re: hide value from list of value [message #628484 is a reply to message #628475] |
Tue, 25 November 2014 11:26 ![Go to previous message Go to previous message](/forum/theme/orafaq/images/up.png) |
cookiemonster
Messages: 13937 Registered: September 2008 Location: Rainy Manchester
|
Senior Member |
|
|
Yup, it's aimed at you, though to be honest I originally thought you ignored LF's suggestion, when actually you both posted at the same time.
I don't buy the argument that if you're doing the extra round trips you may as well commit. Both approaches will result in the same number of round trips (1 extra for post when the user finally clicks on save) and the same amount of data in each trip (commit approach will have slightly more). So the only differences to consider are the effects on the user experience.
If you post you can rollback the changes. If you commit you can't - a savepoint will not get you round that. So post makes the user experience the same as no-post or commit, but now the developer can write queries against the data the user has already entered. Committing all the time takes options away from the user. If the user enters a number of records and then decides to abandon it then post will mean that data disappears but commit means they'll have to actively delete what they entered.
So posting every record has benefits vs committing every record.
I can see benefits of avoiding network trips all together if network is an issue, but that isn't what you were suggesting.
|
|
|