| Calling PL/SQL function in a form [message #430462] |
Tue, 10 November 2009 08:28  |
nathanvijay77
Messages: 22
Registered: October 2008
|
Junior Member |
|
|
Hi...
I am a beginner in Forms and I am building a totally custom form wherein a user can enter the item they want and qty and other features such as colors and based on that system would give a low and high price and user chooses a price anywhere in between low and high price.
I have written function to calculate low and high cost with what users choose as parameters such as material, color etc.
Low Price, High price and price the user puts in are columns in same table.
I tried populating the low price by calling the low price function in property pallete under the formula. This works but issue is till user chooses all the required fields in run time, the system displays FORMAULA_CALCULATION trigger.
Is my approach correct or is there a more efficient way of accomplishing this?
The low price and high price should always get populated from functions and user should not be able to change them and price the users chooses should be between the 2.
|
|
|
|
|
|
| Re: Calling PL/SQL function in a form [message #430471 is a reply to message #430469] |
Tue, 10 November 2009 09:10  |
nathanvijay77
Messages: 22
Registered: October 2008
|
Junior Member |
|
|
Yes,
I already thought about that...using buttons and use when button press trigger.
The issue is according to requirement, user enters raw material,colors and other features and then system should show low price and high price and user chooses a price in betweenthat and then writes to oracle table. I will be using another button to write the data to oracle.
My Q is if I provide a button to find price, how can I hide the button to write data to oracle till low and high price is found and correct price is typed.
Also, if the user changes any of options after calculating price the 1st time, cost has to be calculated again before they can write the information to table.
I am new to Forms and struggling at this moment. Please help
|
|
|
|
| Re: Calling PL/SQL function in a form [message #430480 is a reply to message #430462] |
Tue, 10 November 2009 10:24 |
cookiemonster
Messages: 13938
Registered: September 2008
Location: Rainy Manchester
|
Senior Member |
|
|
If you want to redo calculations whenever certain items are changed the simplest way is to use WHEN-VALIDATE-ITEM triggers on all the items that can cause a recalculation when they are changed.
As for hiding the button, again you can use WHEN-VALIDATE-ITEM.
Create a procedure that checks all the items that need to be populated for the button to be displayed are populated, then use set_item_property to make the button visible.
Call that procedure from the WVI trigger on each item that affects the display of the button.
|
|
|
|
| Re: Calling PL/SQL function in a form [message #430528 is a reply to message #430480] |
Tue, 10 November 2009 20:44 |
nathanvijay77
Messages: 22
Registered: October 2008
|
Junior Member |
|
|
Hi cookiemonster...
Thanks for your reply.
Is it advisable to have users save the data to database using standard functionality of clicking save button or should we provide a separate button and write logic to insert/update records.
The other question I have is if we use separate button to insert/update records, how do we distinguish logic to insert new record vs update an existing queried record.
|
|
|
|
| Re: Calling PL/SQL function in a form [message #430539 is a reply to message #430528] |
Tue, 10 November 2009 23:12 |
|
|
Quote:if we use separate button to insert/update records, how do we distinguish logic to insert new record vs update an existing queried record
Because you are using seperate button tell Insert button to insert and tell update button to update.Check for Uniqueness on Insert.
Jak
|
|
|
|
| Re: Calling PL/SQL function in a form [message #430621 is a reply to message #430462] |
Wed, 11 November 2009 04:10 |
cookiemonster
Messages: 13938
Registered: September 2008
Location: Rainy Manchester
|
Senior Member |
|
|
|
It's always advisable to use default save functionality where-ever possible. So I'd use that and have a WHEN-VALIDATE-RECORD trigger to make sure the user has done all the actions they need to do before saving.
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
