Crud cycle

Question

All the sample applications are grid applications. Present a set of all records with an option to create a new one. No option to update one because update is depend on selecting one of the records.
But we have a need for single record crud. Thus I am having trouble finding an example. I would like to use one form for display, insert, and update.
Our method: first field is the primary key (and not a generated key, a real meaningful primarykey). Upon entering the key, it can be determined if the key exists in the table. (thus need a submit right?) if it does exist, it's then slated for display/update. If it isn't this must be an insert
opportunity. So my question is, can the generated automatic row fetch and automatic row processing be adjusted to accommodate this or
is this always roll your own? I ask because I have been trying to tweak it and not getting anywhere but then I don't understand apex either. It would be really help me if anyone else who tried this could weigh in. The apex processing seems to assume that if there's a key there's an update
and if there is no key it's an insert. Which is not true the way we do things. There always is a key. That's where the problem comes but is there
a way to adjust the apex logic or should I just give up on it?
Here is an example of a non-grid form being created
http://st-curriculum.oracle.com/demos/db/apex/r40/les07_fmontbl/les07_fmontbl_viewlet_swf.html
but it has the problem that it only has an option for insert and no option for update. If it also had an option for update it would be useful
for what I am trying to do.
Edited by: lake on Oct 14, 2010 10:21 AM

Answer 1

Use the wizard to create a form, but don't do tabular form; do one of the other forms. That should get you a single-row form with all the built-ins that you need for processing.
Tabular forms (the grid style) use MRU and MRD (multi-row-update and multi-row-delete) generated processes.
Single-row insert/update/delete forms will instead generate an "automated row fetch" when the page loads and a "process row of xxxxx" process to do the DML.
Unfortunately though, Apex's general model of interacting with the database is that the PK of a table is either 1 or 2 columns (limited to no more than 2) and the values are generated by a function or trigger or sequence (basically, anything out of the user's control). It likes to not let the user enter this. How I design the database tables for this is to make a PK that is a numeric record ID populated by a sequence via a before-insert trigger. I then define the "business" PK as just a unique index on the table. So the underlying PK is just a number with a value that is meaningless for the business use.
Another thought occurred to me just now as I was typiing this. This would be a little ugly for a tabular form (and not entirely sure it's possible on a tabular form) but for a single-record form this might work.
Go through the wizard and built a single-record form on a table. Your PK field will be hidden (OK). Then, add a new field to the form (something like "P1_DISPLAY_PK_VALUE" and make it visible only when the field containing the real PK is null (so user is entering a new record). Let the user define the PK in this P1_DISPLAY_PK_VALUE" field. Then, define a computation that fires when the user is submitting an insert. Set your hidden PK field value to this displayed PK value. In my head, it seems like this would work...maybe give it a try?