This content has been marked as final. Show 14 replies
Greg - Can you show us something that doesn't work right using htmldb.oracle.com? The simpler the better.
I'm running into this exact problem. Did you find a solution?
-- and same problem here -- trying to run a tabular form on a table in another schema.
Any solutions yet?
John - Please see my last response.
I have the same problem: When I create a Master Detail Form, I can only use the "Add Row" button if the table is in the default schema. What is even stranger is that, if I create the same table in the default schema (but still try to use the table in the 2nd schema), the "Add Row" button magically begins to work, even though the data is correctly added to the table in the 2nd schema.
I created an example in htmldb.oracle.com:
I'm new to posting examples so let me know if I need to post more info on how to access the example or configure the workspace differently.
Thank you for that example. I see the bug and now we can fix it. The workaround for now is, as you said, to create a table with the same name in the application parsing schema. It is important that it have the same column names/datatypes as the other table, though, although it does not need to have any rows.
I experienced the same problem and have created a table in my parsing schema with the same name and columns containing no rows.
Can you tell me when this bug will be fixed and how I would receive a patch for it?
I just tried Dan's example (see above) and the problem seems to have been fixed in 3.1.
So you can upgrade to 3.1 to realize this benefit.
I also get this error in 3.01 - Just changed the structure of the underlying table in a tabular form. I then removed a field and renamed another. None of the fields were in the query for the tabular form.
Now I get the error message - report error: ORA-01790
Is there any kind of fix in 3.01. Upgrading to 3.1 is not going to happen for a while. Recreating the form on the new updated structure can be done, but is difficult - there needs to be a better solution!
Did the workaround described earlier not work? How exactly did you carry that out?
Just changed the structure of the underlying table in a tabular form. I then removed a field and renamed another. None of the fields were in the query for the tabular form.
If you could expand this into a full explanation of what you started with, what problems you encountered, how you addressed it, and what's happening now, I'll probably be able to understand your situation better.
A better workaround is to create a view in the default schema of the table in the 2nd schema (a synonym doesn't seem to work).
Seems to me something is still off in 3.1 as well.
I've tried creating a tabular form on a schema other then the parsing schema in 3.1
While all seems be well add row isn't working properly
Strange thing already that although the form is created using the wizzard on schema B if you then look at the columns they all show the application default parsing schema A as the reference schema. After I corrected this the schema B, it is impossible to have a item default value. Giving this same ORA-01790. Changing it back to the original wrong schema A will solve this.
However I still refuses to save. Stating all kind of strange messages as values being null which are not null in the form and datatypes not corresponding which are corresponding.
Ended up removing the entire region, creating a view on the table in schema B and then re-created it as it were an actual table in schema A.