Problem with apex_application.g_fxx.count

Question

Okay, I am at my wits end on this one.
I'm running Apex 4, and on one of my screens I have a manually created tabular report. For one of the master records, this tabular report returns 12 rows, yet apex_application.g_fxx.count consistently returns 24 as the count. For other master records, this is working correctly however, returning the same number as what is showed on screen.
I've tried to duplicate it on apex.oracle.com, but it works correctly there as well.
I've checked the data table, and there are only twelve rows there, same as what the tabular report shows. I've added in TONS of code to report back what is happening and everything looks fine in the code and processing, but the data that gets saved is out out sync, since it appears that for some reason the xxx.count (for only this one master record) is somehow doubling the count, so the data that gets saved is off. For example, say someone makes a change to the third sub-record, the 'count' suddenly becomes 6, so it saves the changes for the sixth sub-record.
Has anybody else ever seen this phenomenon and knows what causes it? I've spent three fruitless days trying to track this down so far.
Thanks,
Bill Ferguson
A bit of further information.
In my app, users must list all commodities present at a site first (different screen). They may then go to my Resources screen and input the tonnage and grades of the various commodities present. This ensures that users cannot add tonnage and grade information for a commodity that is not listed as being present at the site.
So, when they get to the Resources screen, the bottom is all filled out with all of the commodities listed, and they simply have to type in the grade. The users also wnated the ones with information in the grade fields to appear at the top, so I had to add an order by to the query, as follows:
SELECT a_rec,
       c_code,
       import,
       item,
       grade,
       grade_units,
       child_key,
       count_order
  FROM (SELECT rec a_rec,
               c.commod || ' - (' || code || ')' c_code,
               c.import,
               item,
               grd grade,
               grd_units grade_units,
               child_key,
               rec count_order
          FROM    RESOURCE_DETAIL rd
               RIGHT OUTER JOIN
                  commodity c
               USING (dep_id, code)
         WHERE (CHILD_KEY = 1028244420100003)  -- actually using a variable here instead of hard-coded values
        UNION
        SELECT c.line a_rec,
               c.commod || ' - (' || code || ')' c_code,
               import,
               NULL item,
               NULL grade,
               NULL grade_units,
               NULL child_key,
               c.line + 200 count_order
          FROM commodity c
         WHERE dep_id = 10282444 -- actually using a variable here instead of hard-coded values
               AND code NOT IN
                      (SELECT code
                         FROM resource_detail
                        WHERE dep_id = 10282444 AND yr = 2010 AND line = 3)) -- actually using variables here instead of hard-coded values
ORDER BY import, count_orderNow, on the screen the commodities are listed as:
Copper
Gold
Molybdenum
Silver
Gemstone
Lead
Zinc
Uranium
Gypsum
REE
Talc
Garnet
But, the code I've added to see what is happening is instead saying the records being processed are in this order:
Copper
Garnet
Gemstone
Gold
Gypsum
Lead
Molybdenum
REE
Silver
Talc
Uranium
Zinc
I do not have any sort criteria specied in the Report attributes. So, why is the order of processing (for i in 1 .. apex_application.g_f03.count) processing in a different order than what is shown on screen?

Answer 1

Hi Arie,
This was a strange one to track down. I wound up adding all kinds of logging statements in my code, writing things out to a table while processing, counts, which record, etc., and suddenly it dawne don me that everything was being processed in alphabetical order by commodity name, even though the screen display was by two other fields. I played around with different 'order by' settings, but the processing somehow was always by the commodity name. I have no idea where it was getting that 'directive', but nothing I could figure out changed it.
So to recap, in case I didn't explain it well enough above, this is a manually created tabular form, with a 'regular' form above it (master-datail). I use the apex_item.text, etc. constructs to create the tabular form, and then in my 'proceses' I'm using the normal apex_application.g_fxx array to perform the processing. While the screen display from the tabular report shows everything with an order by of two columns, the processing always was done ordered by a diffierent, no-specified column.
Changing my report definition to use the same 'order by' as the processing seemed to be working fixed the problem, though I have no idea where it was getting the 'order by' from to overwrite what was being on screen. I'm not sure if this is a bug or not, I vaguely remember Scott Spadafore commenting about this behaviour a long, long time back, but I can't find the post. It was probably back in the 2.x days.
I also have no idea what is causing the array to somehow double for some records and not on others. In this particular case, the record I had on screen only had 7 commodities, but when I printed the result of apex_application.g_fxx.count, it always showed 14, even though on apex.oracle.com, when I tried to re-create the problem, it worked correctly and only reported 7. Most records in my database that I tested this on worked correctly, reporting the correct number of commodities, but occasionally I'd run across one where the number was doubled. I don't know if there is some internal table Apex uses that I could truncate (like possibly wwv_flow_collection_members?) where possisbly this type of information be kept. The only thing I can think of is that somewhere these counts are stored in a collection and it is populated with data from a real old incarnation, and during processing it stumbles across these old records and uses the old values. It doesn't seem like a realistic possibility, but it about the only explanation I can think of.
Bill Ferguson