Developer 2.1 -- Storing Forms in the Database -- PECS

Listers,

I haven't stored a form in the database since SQL*Forms 3.0, when it was necessary to do so to have object reuse via referenced objects. In Developer 2.1, in what tables is this data stored? We have run all the appropriate build/grant scripts for tools, forms, ros, etc. But, when saving a form into the database, no data shows up in FRM50_OBJECT. I am probably really missing the boat on something here.

To back up and explain why the FRM50_OBJECT is of importance, what I am trying to do is use PECS to gather statistics on a massive and very convoluted form that I have been asked to tune. Initial code review has turned up some issues, and, I have already run a trace on a typical session, tkprof'd the output, and examined the SQL, plans, gets, execution times, etc. Things are fine from that standpoint. Users aren't seeing slow performance due to the SQL being executed by the form.

I have run the form using PECS to gather statistics. The data has been loaded through PECS and the output from the PECS form is useful. The only thing I am running into is, just for an example, a WHEN-VALIDATE-ITEM trigger in the PECS output does not include the block and item when drilling down into the detail. This applies to all the code related to blocks and/or block.items.

Examining the PECS code, there is a procedure that gathers and summarizes the data. This procedure has a cursor selecting from the FRM50_OBJECT table, using the modid and the itemid to get scope1 and scope2. These two values are then inserted, along with the statistics, into a summary table with scope1 and scope2 related to block and item respectively. The problem I am having is that even after saving a form to the database, nothing shows up in the FRM50_OBJECT table. So, in the detail output of PECS, there is no block.item scope for the various triggers and such.

We have no problems saving a form to the database and then retrieving it. We are just trying to find exactly where the data is stored so that we can resolve the modid and itemid to the actual forms object. Once we do that, we can modify the summary procedure as appropriate and tie the various triggers and such back to a specific item, block, etc. The PECS procedure, as it is now, looks to resolve this information by hitting the FRM50_OBJECT table, and, there is nothing there when a form is saved. And this isn't a case of a view on top of a table restricting access by the user. In the case of FRM50_OBJECT, it is actually a table called FRM50__OBJECT (two underscores) with a synonym called FRM50_OBJECT (one underscore). Select privs are in place. When testing against Forms 4.5, the data shows up in the FRM45_OBJECT table.

Very lost at the moment,

Larry G. Elkins
The Elkins Organization Inc. Received on Thu Jun 22 2000 - 19:36:14 CDT