Row Fetch on View doesn't work / Custom procedure needed???

Question

Hello guys!
Again I have a problem. It seems like once I finish one problem I stumble into another one. :-(
Would is breaking my neck is the following problem.
I have a view based on a query that joins 3 tables including one via a database-link. I would like and need to use that view as the source for the automatic row fetch! However, when creating the automatic-fetch-row process, the items on my page do not get populated. However, If I change the cource for the fetch-row-process to a view made of only a single table it works like a charm. Could it be that the automatic fetch-row procedure doesn't work with joined views and db-links at all??? If so, could you please give me an example of a PL/SQL procedure that will populate items on page reload and load!
It's extremely urgent and I appreciate every input!
Thanks guys! I hope you some ideas and hints!
Regards,
Sebastian

Answer 1

Ah, ok - I probably read too much into your update (still thinking that it was related to the "view" issue in your first post :) ) - so an INSTEAD OF trigger won't be needed if this is just a single table!
There are a few ways that adding an extra column into a tabular form would stop it being updated. Typically, this could be if the new column forms part of the "Primary key" for the data. If this is the case, you need to ensure that the processes recognise this. It can also be that you have set the item to DISABLED or READONLY - these items are not submitted with the page, so even if you set the item's value somehow, that will never get back into the record (there are ways to take off the DISABLED or READONLY attributes immediately prior to the submit, if need be). That could also happen if you have set the item to be a Standard Report Column - this is just displayed text, so doesn't form part of the submitted data. You can get around that by having a hidden column with the actual data in there as well - if you have ever created a tabular form using the simple EMP table example, you'll see EMPNO and EMPNO_DISPLAY - both contain EMPNO but only the basic EMPNO hidden item is submitted. Another, perhaps rare, possibility is if you have used the APEX_ITEM package to create any of the output and have used an index number that has been automatically assigned to another column - for example, if you have APEX_ITEM.TEXT(1, ....), which gives each item a name value of "f01", then this is most likely going to double up with the index for the hidden primary key item (which is usually first in the list). If this is the case, just change the index of your APEX_ITEM item to some high number (anything up to 50).
Finally, you say "INV_PT_ID_SUB is also bound to an item PTIDS" - what is PTIDS? The MRU processes need to understand what column to update and relies on the settings for primary keys and the column names in the SQL query.
The MRU's only know about their own settings - the workspace, tablename and primary keys etc. They contain no details of individual columns as such, so adding in extra columns shouldn't be a problem. In fact, I've added/deleted so many columns from tabular forms, that I'd be really annoyed if I had to start from scratch every time!!
Andy