Re: SQL*Forms, default block create, and views

kcameron_at_erc.cat.syr.edu (Ken Cameron) writes:

>I would like anyothers to try to verify this and tell if this is a feature
>or a bug of Forms. When using the create block default selection to build
>a master-detail in a form and the 'table' is really a 'view' it doesn't
>create all the trigger and proceedure logic as it does for a 'table'.

I'd call it a feature to keep you out of trouble.

I've thought about doing this on occasion too, but there are problems. Since you can't insert into a view with a where clause, A form can't be allowed to do anything but query. I've always used SQL*Forms own capabilities to simulate access to a view.

There is, of course, nothing preventing you from using a trigger to fill fields from a view.

>Now the example I have is slightly twisted since the form will use a number
>of views of the same table. The way is that each view is logicly a sub-
>set of common data but to the users they need to think it's totally
>different data sets. Yes the views have WHERE's and the like so that in
>SQL*Plus it seems to be the separte files of data.

Why don't you split the data into actual separate tables with indexed foreign keys?

>Any help will be appreciated. For now I create the default block using the
>table, then edit the *.inp file to switch the names from the table
>to the view.

Mad fun, and it might work for query, but you'll have to prevent inserts, updates and deletes, or write custom triggers to handle all the different possibilities by going straight to the table.

-- 
"Well, it's rather brutal here.  We're   | dave_at_msb.com (Dave Lockwood)
advising all our clients to put every-   | UUCP: ...!uupsi!mpoint!dave
thing they've got into canned food and   | Sysop of Meetpoint Station BBS
shotguns." - Brain Gremlin (Gremlins II) | cat flames | mail santa_at_north.pole