This content has been marked as final. Show 15 replies
I'm not quite sure want you want to achieve. I'll try anyway:
1. Every time the user changes some data in a record, you force him to enter an explanation in a textbox.
2. This explanation should be saved in a log-table when the record itself is saved.
so far, so good, but..
What does not work?
What do you want to achieve with the KEY-NEXTITEM-trigger?
What do you want to achieve with the global?
What is that about the GET_RECORD_PROPERTY-call in KEY-COMMIT?
Thanks for your help.
Actually, my application has already a window that forces user to provide the change reason. Although, it has been fired when forms is committed.
When I say that it does not work, it means that Forms 'understands' that field was changed even by user navigation.
For example, if user executes the query the GET_RECORD_PROPERTY built-in gets the status = 'changed' even though there's no changing. Please see below:
GO_ITEM('ESB_COD'); /* Focus on the field now.
But if I check the Record_Status in this time is Changed
due to the Focus on the field */
IF GET_RECORD_PROPERTY(1,'ESB_COD',STATUS) = 'CHANGED'
I hope to have been more clear.
Thank you, again.
if the recordstatus is changed just after the query there is normally some cros validation occuring from reading lookup values in the POST-QUERY.
Do you have a POST-QUERY-trigger on your block? If so, issue a
at the end of it. Then the recordstatus should keep QUERY until a "real" change occurs
SET_RECORD_PROPERTY('BLOCK', TO_NUMBER(:SYSTEM.TRIGGER_RECORD), STATUS, QUERY_STATUS);
Tell us what triggers are running when user navigates to next field. Is there a key-next-item trigger that changes something? Is there a when-validate-item or post-text-item trigger that sets a value in your record? Look for a when-new-item-instance trigger, too.
Those things are what cause record status to become "CHANGED" when you navigate to another field.
I have WHEN-VALIDATE-ITEM in my 1st field(estab_cod) just to check if the estab_cod>0. KEY-NEXT-ITEM is just to populate the other forms fields.
Note: In the other forms fields - trigger K-N-I, I just put 'next_item'.
There's no other code for the fields.
In the block level, there's KEY-COMMIT and POST-QUERY - where I put the code SET_RECORD... as issued above.
I have WHEN-VALIDATE-ITEM in my 1st field(estab_cod) just to check if the estab_cod>0.If there is no assignment in this trigger, it should not be a problem
KEY-NEXT-ITEM is just to populate the other forms fields.This sounds like it could cause the problem, please post the code (generally this logic "populating the other forms fields" should also be in WHEN-VALIDATE-ITEM-triggers, for it should be executed only if the field value changes and not for every navigation).
Note: In the other forms fields - trigger K-N-I, I just put 'next_item'.If just a next_item in the the KEY-NEXT-ITEM-trigger, then delete it for this is the default-functionality.
are the form_fields in the INTO-clause fields in the same block ? If so, you have your error-cause.. When has this code to be executed? When the user changed the value of the current item? If so, put the code into the WHEN-VALIDATE-ITEM-trigger. If it could be read immediatly after the query it should be in the POST-QUERY-trigger.
AS_Anderson wrote:In Forms, that is not the correct way to populate data into a block. You need to use Execute_Query instead. Forms automatic processing creates and executes the query in the background.
Here is the sample Code:
SELECT column1, column2,...columnN
INTO form_field1, form_field2...form_fieldN
FROM ESTAB_TABLE, CITY_TABLE, STATE_TABLE, COUNTRY_TABLE
It sounds like you want to populate data from the ESTAB_TABLE after the user enters a key value in :form_estab.esb
What you really should do is create two blocks, on a control block (I usually name it B1), and then your FORM_ESTAB base-table block.
Create the field ESB in block B1. When the user enters a value in B1.esb, you could then have a key-next-item trigger that does this:
In the Form_estab block, put a where clause:
estab_cod = :B1.esb AND (TABLE JOINS)
As you had told me, there was values attribution in some triggers which then modified the block status.
Actually, it was a new situation for me due to this new project.
Thanks for your help.
Taking advantage to this opportunity, do you know some good book to Oracle Forms Developer?
I've performed the Oracle 10g Forms and Reports Courses in an Oracle Official, but I rather need to improve my knowledges and start in a advanced code for this project; using, for example, dynamic sql in forms.