Oracle Forms 9 Problem

Question

I am learning forms with Oracle 9i and have run into a problem.
The following code runs just fine in a Save Button with a WHEN
-BUTTON-PRESSED trigger that inserts a record from a stacked single
record block (does not allow updates or deletes from it).
DECLARE
edit_alert alert;
show boolean := false;
message varchar2(150) := 'You Must Fill the Following Fields:';
choice number;
BEGIN
IF :add_region.region_id IS NULL THEN
show := true;
message := message || CHR(10) || '----- Region Id';
END IF;
IF show = true THEN
edit_alert := Find_Alert('EDIT');
set_alert_property(edit_alert, ALERT_MESSAGE_TEXT, message);
choice := show_alert(edit_alert);
ELSE
insert_record;
commit;
clear_block;
go_block('regions');
END IF;
END;
But when I try to use the following trigger on a Save button which is
almost identical on a table canvas with a multi-line block that allows
queries, updates and deletes...it basically skips the IF....IS NULL
section because the show never turns true and the alert never fires so
it automatically trys to update the record, but fails because of the
null value. It works perfect if the item is not null and gets inserted.
I figure that it has something to do with :regions.region_id within a
multi-line block and the if statement not knowing the current record.
I have searched and searched for a solution with no luck. Can anyone
help?
DECLARE
edit_alert alert;
show boolean := false;
message varchar2(150) := 'You Must Fill the Following Fields:';
choice number;
BEGIN
IF :regions.region_id IS NULL THEN
show := true;
message := message || CHR(10) || '----- Region Id';
END IF;
IF show = true THEN
edit_alert := Find_Alert('EDIT');
set_alert_property(edit_alert, ALERT_MESSAGE_TEXT, message);
choice := show_alert(edit_alert);
ELSE
update_record;
commit;
END IF;
END;
I appreciate any time and help....
Michael

Answer 1

You say the forms don't work that waySteve said standard forms don't work that way. Your teacher may want to see working programs but (s)he might put more emphasis on your understanding of the forms environment, in which case using standard practices would be best. It's better to be standard in the real world too, although sometimes you really do just have to get something to work before a deadline.
As an example of non-standard practices being bad, consider your idea of having validation/committing in a button. This is Ok as long as the user always presses the button but there are other ways to commit the data, such as closing the form, executing a query or navigating to a new record in a master block. That validation code will not run in those circumstances. Always use a when-validate-* trigger or the property pallette for validation.
Your on-error trigger is also bad. Firstly, do you know why it is firing? Is it because there's a not-null restriction on the region_id item and a null value in the field? If it's firing for any other reason, such as because there is a duplicate record or the database has shut down, then the user will never know because you're overriding standard functionality. If it is firing because of the not-null restriction then a user who does put a value in there will not have their country_id checked at all.
There may be other reasons as well but the on-error trigger is certainly firing because you're calling the update_record procedure in a button. That built-in is only allowed in an on-update trigger (it's annoying that forms will compile with errors like this but that's just the way it is). This will only cause it to fire once, so only the current record will be validated.
Your foreign key integrity check is wrong. You're usingWHERE UPPER(country_id) = UPPER(:locations.country_id);so if I enter FranCe and FRANCE is on the database the program will not see a problem. That's Ok as long as throughout the system you refer to upper(country_id), but this will negate an index on that column so should be avoided. The standard method is to use an LOV and to set the item to 'Validate from List = true' (property pallette). Also, it's very rare to validate an item other than in its own when-validate-item trigger. The exception is paired items such as the start/end of a date range, where one date must precede the other and it's more user-friendly to validate both fields together.
I can't see why the "if...is null" won't work in the WVR trigger, but if you use standard practices throughout the form and that is the only problem then you're much better off than now.
For the path, use "get_form_property(<module_name>,file_name)" and strip off the <module_name>.fmx part. It seems you have a valid reason for not being standard here (using environment variables) so that's Ok ;-). Good luck with the assignment.