For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!
I've recently migrated from APEX v5 to v19 and am having some trouble creating reports and forms on tables in schemas outside the main workspace schema. You can see from the screenshot below that I can currently only see the 'Parsing Schema' and one other database schema called 'DO' in the Table Owner dropdown menu that's within the Source of the report. I'd like to be able to see tables from two other schemas, i.e. 'GIS' and 'PROD'. So far I have managed to log in to the INTERNAL workspace as ADMIN, and have assigned the schemas using the 'Manage Workspace to Schema Assignments' page which looks as follows... You can see that I have successfully added the DO, GIS, and PROD schemas. But when I log in as the workspace admin in order to create tables or forms in an application, I only see the DO user schema in the dropdown for the source of the table or form. How can I fix it so that I can see the GIS and PROD schemas in Table Owner dropdown so that I can access those tables? If it helps, you can see a table report that I originally set up on APEX v5 that was able to access the GIS schema (because I was able to actually type 'GIS' as the table owner instead of being restricted by a dropdown menu)... Now it shows as 'GIS (Invalid)' but it still works.
Need more details, including the Forms and DB versions you are using. Are you using Forms blocks based on DB (i.e. "Data Blocks") or you are executing your own DML and populating (and altering) fields or both? And, how are you "committing" (COMMIT_FORM, or Save button or something else)? Be specific; if you are executing the "COMMIT" - are you using COMMIT or COMMIT_FORM?
Using Oracle Forms 12c and Oracle DB 19. Yes, I'm using data blocks, based on tables from DB. User clicks a button to save and I'm doing a COMMIT_FORM. Thanks, Marc L
Here's part of my Key-Commit code: Marc L
Hmmm - If you are using a true "data block", there is often little reason to execute your own POST. Forms will do this automatically as soon as a the first change is made. This will result in a record lock. I'm not saying that doing a POST (or COMMIT_FORM) is a bad thing. I'm just saying that in a block managed by Forms, most of the "right" processing will happen automatically (a benefit of using Forms). To your question, I have not tested, but suspect the behavior based on your description of what you are doing, is correct. Validation must occur upon POSTing, but also again when COMMITing. If you look at the Builder Help related to POST and COMMIT_FORM you will see that it supports this belief. If you wanted to continue on this path, it might help to change the Validation Unit property (form level), as this might offer some relief. Of course doing this could also change the desired behavior of something else. Again, check the Builder Help for details on this property.