Path: utzoo!attcan!uunet!ns-mx!vaxa.weeg.uiowa.edu!broy From: broy@vaxa.weeg.uiowa.edu (Barbara Roy) Newsgroups: comp.databases Subject: Re: SQL*Forms V3.0 -- Multiple detail relations? Message-ID: <2797@ns-mx.uiowa.edu> Date: 18 Oct 90 18:42:22 GMT References: <1990Oct18.152751.11893@oracle.com> Sender: news@ns-mx.uiowa.edu Reply-To: broy@vaxa.weeg.uiowa.edu Distribution: comp.databases Organization: U of I - Weeg Computing Center Lines: 44 News-Software: VAX/VMS VNEWS 1.3-4 In article <1990Oct18.152751.11893@oracle.com>, kbittner@oracle.uucp (Kurt Bittner) writes... > > 1) Use the CONSTRAINT capability provided in the Oracle RDBMS to define the > primary key/foreign key relationships when you create the tables. > It is also a good idea to code CHECK constraints into the table definitions > since Forms 3 can use these to automatically generate validation triggers > if you select "Use Constraints" on the default block screen. Oracle documentation and Oracle class instructors indicate that CONSTRAINT definitions are NOT supported until version 7. Does SQL*FORMS 3.0 use them while the RDBMS does not? > 2) Use the Block Default option to define your blocks. When you define the > "detail" block, indicate that the "master" block is the master block. > If you press "List of Values" while in the "master block" field, you'll > get a pop-up menu of all valid master block choices based on blocks > already defined having a foreign key reference in your current table. > Selecting the master block will define the relationship automatically. This works fine for the first detail block, but I have had to manually create the appropriate triggers for all subsequent detail blocks of the same master. I haven't tried using your CONSTRAINT suggestion. Is that what corrects the problem? If so, why didn't tech support clue me in (ref TAR# 99530.41). I was told it was a bug that would be corrected in the next release. There is also a problem that if you delete all blocks in the form, the clear_details and query_details procs aren't deleted. Then when those blocks are added back to the form, the procs aren't re-created. > 3) Generate the form. > >That's it. (Of course you can always do all the work manually; if you want to >see what needs to get done, look at all the triggers forms generated for the >default block.) > >Kurt Bittner "My opinions are, humbly, my own and are not likely to >Consultant be shared by anyone, let alone my company." >Oracle Corporation Barbara Roy, Weeg Computing Center, University of Iowa, Iowa City, IA. 52242 Phone: 319-335-5506 Internet: broy@vaxa.weeg.uiowa.edu Bitnet: broyva@uiamvs Disclaimer: My opinions are solely my own and may change daily.