This tutorial is designed to walk you through chapter 2 of the Oracle APEX Advanced Tutorial, Creating a Tabular Form. It is in 2 video parts, with part 1 covering actual application and form creation, and part 2 covering extending the capabilities of the form.
If you haven’t already, please review our APEX Tutorial Preparation and OEHR Sample Data Install Video Walkthrough.
Part 1 – Creating the Application and Form
Part 2 – Extending the form
High Level Steps
Before you begin, go through our APEX Tutorial Preparation and OEHR Sample Data Install.
1) Login to Apex (0:24)
2) Create Application (1:00)
3) Create Form (3:46)
4) Run and verify Form (7:40)
5) Extend Form (0:19)
6) Test extended Form Functions (4:51)
Times in parenthesis are the approximate start time for that step.
Notes and Details
It is important that the account you log into in APEX has at least Developer level rights, or Workspace Admin rights. You also must use an account (of this level) that has access to the workspace that the OEHR sample data was installed to. For a walkthrough of this process, there is a link above to the OEHR install tutorial.
This screen of the application creation process gives us the option of how to authenticate our users. For most of these tutorials we will use the APEX (Application Express) authentication option. Only users setup within the APEX system will be available to use the application. The No Authentication option allows anyone to use the created application, and Database Account allows you to use the Database Authentication model. This last one is most useful if APEX is installed against a full Standard or Enterprise Oracle Database install.
This screen allows you to specify which scheme setup will be considered the ‘owner’ or the given page, as well as set the primary overall level of capabilities for the end user. You can limit whether a user can Update, Insert, Delete, or a few combinations of those activities in the page. Note you can also allow/disallow these options by editing the page itself and removing the buttons from inside the page editor screen itself.
This allows you to select either the defined primary key for the source table, or a different key. You can also select a second key column. You also can alter the source for the key trigger.
Again, any column attributes can also be edited from the report editor at any time, as well as additional features that are not included in the base wizard.
Branching is the process by which you can define the behavior of the application when an event occurs. In this case, you can select what page of the application will be brought up when the ‘Submit’ (Apply Changes) button is pressed. This allows you to branch off to confirmation screens, or secondary data input screens, or by putting in the same page number as the page your creating, just refresh the existing page.
Dynamic List of Values
The SQL query that drives the LOV’s in a dynamic state give you a built in sort of help by typing out the basic framework of the query for you. They also allow you to have different values for displayed and returned values. In this case, you could make it so rather than the department ID being both the display and return, you could make it so the department name is displayed, but it’s value is returned (User would see the Dept name in the drop down list, but when any updates are committed, the ID is actually what is altered). You can also choose to have null value display (IE a ‘please select one’ option) if there is no set value for that field already.
Many of the topics touched upon will be revisited in later tutorials, and of course, you can experiment yourself with the APEX system to further your understanding of it’s conventions and workflow patterns.