How to keep transaction control in a wizard of more than one page

Question

How do I control a transaction across multiple pages with multiple row DML?
I have a complicated business process. I want to build a wizard in my application. For example, to apply for a loan from a bank. A sequence of pages to take the user through a series of steps in the process, click Next and Previous to navigate the pages, click Cancel to undo, click Ok on the final page to commit work.
I know there is a wizard widget in HTMLDB to generate pages 1 .. n in a wizard. But ...
My question is this? How do I control the transaction. How do I stop HTMLDB commiting the steps as I go along. Somehow I want HTMLDB to remember all the information. I want to save everyting or nothing at the end of the process.
I know this works if each page is a form with items. You can build a summary page. But what if a step requires multiple rows.
For example
Step 1 : A report to select Department to a form to Create/Update department
Step 2 : A report to Form to Create/Update/Delete all Employees for that department.
Step 3 : A report to Form to Create/Update/Delete some other thing for that department.
What if
I update department Sales, press Next, delete employee Rod, create employee Jane and Freddy, press Next. I have a change of heart to decide not to hire Jane and Freddy but keep Rod on to give him a second chance so I press Cancel on Step 3. HTMLDB has already saved the changes to the employees. How do I rollback to the original state of the world.
1 ) f_g memory structures? No. I know I can get at a data structure if I use a multiple row update tabular form. Using the htmldb_application.f_g0n index by tables in the database. But I do not think it is possible on page x to get at the arrays for both the current page and the previous page? I dont want to use a tabular form in any case.
2 ) Database Memory Structures ( in package x create type t is table of t%rowtype; ). No.
3 ) Global temporary table ( create global temporary table t .. on commit delete rows )? No.
2 + 3 is not an option because HTMLDB seems to me to use a connection pool. The session in the browser is constant. The session to the database USERENV('SESSIONID') may change every time you click something or refresh the page. In the web model every time you request an action you connect to the database with a new session.
3) My solution. Have a copy of all the relevant tables. Do dml on the copy using the htmldb session as a unique identifier. Then to move the data from the copy tables to the real tables at the end of the process. Hope I catch all the cancel events to delete data from the copy tables. Just in case run a batch job run in the night to clean out the copy tables assuming no one is using the process at the time.
My solution is ugly ! There must be a better way ?

Answer 1

Ahhh, sorry for the confusion. What you need are "Collections". If you click the "Review Demonstration Applications" link then install the "Collections Showcase", this should give you a good working sample.
Collections are comprised of an HTMLDB_COLLECTIONS package and an associated table. Use the package for creating a collection and adding members (rows) and use the table to query what's in your collection.
Essentially, here's what you need to do. Let's assume your multi-row form is on page one and you have a confirmation page on page 2:
- Create a process that fires on submit of page one that uses create_or_truncate to create your collection.
- In the same process, loop over your collection items and add them (as members) to the collection.
- Make sure your multi-row form queries from the collections view. This way if you go to page 2, then back to page 1, you will see your rows. When you go to page 2 again, you can just over-write the existing collection. There's another option, but I'll list that later.
- Create a process on page 2 to loop over the collection view and insert the rows into a table. Make this conditional based on the button you press, such as "Save".
- Extra credit: Either the collections package or the htmlb_utilities package as an md5 function. You can call this when querying the data out of the collections table, then call it again as you are looping over the data on submit. Basically, you are checksumming the row on the way out, then again when the page is submitted. If the 2 are equal, the data is unchanged. If they are not equal, the data has changed. Based on your needs, you can use this technique to insert / update records. I have an app that uses this technique because I have a before update trigger on the table that I only want to fire if the user actually updates a particular row.
Hope this helps,
Tyler