Accessing wwv_flow_files changed after upgrading from 2.0 to 2.2

Question

We have recently moved to 2.2 After the move uploading files, under some circumstances, failed.
Further investigation found that the upload was working fine, accessing wwv_flow_files table had changed in some way.
From the SQL Workshop we could see the files which had been uploaded. From SQL*Plus we couldn't see the same files.
I have read Re: Lost permissions on WWV_FLOW_FILE_OBJECTS$ and see at the end it says that access to wwv_flow_files is not supported from SQL*Plus. That's fine.
The problem we have is that the same limit seems to apply to functions called from within an APEX application. We have a function that at one point issues the following SQL -
SELECT blob_content
INTO l_blob
FROM wwv_flow_files
WHERE name = p_file_name;
(The function goes on to extract rows from the uploaded file to be uploaded into a table).
This function was not able to find the row which we knew was in the table.
Drilling down wwv_flow_files is a view of wwv_flow_file_objects$ with the following condition 'where security_group_id = wwv_flow.get_sgid'
By changing the original SQL to
SELECT blob_content
INTO l_blob
FROM WWV_FLOW_FILE_OBJECTS$
WHERE name = p_file_name
AND created_by = 'HTMLDB_PUBLIC_USER';
we get what we want.
My question is .. as the function is called from with an APEX application, why is the where clause preventing it from accessing the data we need.

Answer 1

Thanks for the details, it's making more sense to me.
The function extracts the rows from the uploaded file and displays them in a textarea.When you say "and displays them in a textarea" it sounds like something that happens during page rendering. But I think maybe your page selects the rows in an after-submit process and puts some content into a textarea item for display during the next page "show". Tell me if I'm on the right track. In 2.2, there's a bug that prevents queries from seeing the just-uploaded "files" or rows until after computations have fired. You need to move any code that selects those rows to a process "after computations and validations" (you could run it as a validation if you really needed to). Let me know if you think this explains what you're seeing. This is fixed, by the way, in 3.0.
The created_by = 'HTMLDB_PUBLIC_USER' clause is required as the >>WWV_FLOW_FILE_OBJECTS$ table also contains objects created by other users, for >>example ADMIN (eg APP imports etc)But your predicate specifies "where name=" and name has a unique constraint so you'll get the row you want without specifying created_by.
Scott