Stupid question about Primary and Secondary

Wed Nov 14 08:52:53 CST 2007

Although I can't comment on the enhancement request at this time, other
than to say it's on my list and I fully understand why it's
needed/wanted, I couldn't help but jump in to comment on Ken's
observation.

As it happens, the person who is considered the creator of QTP did write
QDESIGN.

This is one of those anomalies that we can't change for historical
reasons. By default, GET verbs are required. There is some logic around
PRIMARY and DETAIL gets to handle situations in the FIND and DETAIL FIND
procedures. However, if you do a GET on a SECONDARY without saying
OPTIONAL, it's required. QDESIGN generates (and has always generated as
far as I know) the GET OPTIONAL for SECONDARY files in the FIND and
DETAIL FIND regardless of whether you have OPTIONAL on the ACCESS
statement. 

So the requested REQUIRED option would only apply to the OPTIONAL
generated in the FIND and DETAIL FIND because it's not needed elsewhere.

Bob

________________________________

	From: powerh-l-bounces+bob.deskin=cognos.com at lists.sowder.com
[mailto:powerh-l-bounces+bob.deskin=cognos.com at lists.sowder.com] On
Behalf Of Ken Langendock
	Sent: November 14, 2007 9:25 am
	To: fernando.olmos at hpa.com.au; powerh-l at lists.sowder.com
	Subject: RE: Stupid question about Primary and Secondary

	True, but I understand the original design, I'd just like to
have the option of creating a link that is REQUIRED before a record is
retrieved just like in QTP.

	Access Employees &
	  link to Security

	The same in Qdesign would be:

	File Employees Primary

	File Security Secondary REQUIRED

	Or you are correct it might have been better to code Qdesign
originally like this:

	File Employees Primary

	File Security Secondary (REQUIRED automatically unless the
programmer adds OPTIONAL)

	I think that if the same programmer who created QTP wrote
Qdesign, it might have happened this way. But I know that would be a
change that will NOT happen at this point so the REQUIRED option would
be a nice to have enhancement.

	Ken

________________________________

	From:
powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com
[mailto:powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com] On
Behalf Of fernando.olmos at hpa.com.au
	Sent: November 13, 2007 11:35 PM
	To: Ken at Langendock.com; powerh-l at lists.sowder.com
	Subject: RE: Stupid question about Primary and Secondary

	Thanks Ken.

	I guess the logic behind this is to "encourage" the developer to
note that all links to the primary table are optional by default and
should be, in the case where the underlying tables do not yield any
data. Therefore, "some" data will be available to the user if the screen
was hashed out quickly - so to speak, to give something to the user. Of
course when screens are developed, they seldom stay the way PH intended
them to stay!

	cheers

	Kind regards, 

	--- 
	Fernando Olmos 
	Senior Analyst Programmer 
	HPA - A Salmat Company
	Direct: 02 9311 5411
	Fax: 02 9311 5166
	Mobile: 0434 879 784 
	www.hpa.com.au
<outbind://72-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC
45B9843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000
660A050000/www.hpa.com.au>  

		-----Original Message-----
		From: Ken at Langendock.com [mailto:Ken at Langendock.com] 
		Sent: Wednesday, 14 November 2007 3:28 PM
		To: Fernando Olmos; powerh-l at lists.sowder.com
		Subject: RE: Stupid question about Primary and Secondary

		There is no way currently to do what you want. I
requested an enhancement with Cognos to add a "REQUIRED" option to a
secondary file to do this.

		Until then Hard code the find and comment out the
OPTIONAL on the secondary GET

		Ken

________________________________

		From:
powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com
[mailto:powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com] On
Behalf Of fernando.olmos at hpa.com.au
		Sent: November 13, 2007 7:28 PM
		To: powerh-l at lists.sowder.com
		Subject: Stupid question about Primary and Secondary

		I thought that the following code would make the
ORDER_MASTER table *not* optional! 

		> screen ert 
		> file customers in isdb 
		> file order_master in isdb secondary 
		> build list detail 

		> PROCEDURE PATH 
		>   BEGIN 
		>     LET PATH = 1 
		>     END 
		> PROCEDURE FIND 
		>   BEGIN 
		>     GET CUSTOMERS SEQUENTIAL 
		>     GET ORDER_MASTER OPTIONAL 
		>     END 

		Yet it does. Why? 

		How can I declare the FILE statement to not place an
OPTIONAL on GET ORDER_MASTER? 

		Thanks 

		Kind regards, 

		--- 
		Fernando Olmos 
		Senior Analyst Programmer 
		HPA - A Salmat Company
		Direct: 02 9311 5411
		Fax: 02 9311 5166
		Mobile: 0434 879 784 
		www.hpa.com.au
<outbind://72-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC
45B9843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000
660A050000/www.hpa.com.au>  

**********************************************************************
		IMPORTANT
		The contents of this e-mail and its attachments are
confidential and intended
		solely for the use of the individual or entity to whom
they are addressed.  If
		you received this e-mail in error, please notify the HPA
Postmaster, postmaster at hpa.com.au,
		then delete  the e-mail.
		This footnote also confirms that this e-mail message has
been swept for the
		presence of computer viruses by Ironport. Before opening
or using any
		attachments, check them for viruses and defects.
		Our liability is limited to resupplying any affected
attachments.
		HPA collects personal information to provide and market
our services. For more
		information about use, disclosure and access see our
Privacy Policy at
		www.hpa.com.au

**********************************************************************

**********************************************************************
	IMPORTANT
	The contents of this e-mail and its attachments are confidential
and intended
	solely for the use of the individual or entity to whom they are
addressed.  If
	you received this e-mail in error, please notify the HPA
Postmaster, postmaster at hpa.com.au,
	then delete  the e-mail.
	This footnote also confirms that this e-mail message has been
swept for the
	presence of computer viruses by Ironport. Before opening or
using any
	attachments, check them for viruses and defects.
	Our liability is limited to resupplying any affected
attachments.
	HPA collects personal information to provide and market our
services. For more
	information about use, disclosure and access see our Privacy
Policy at
	www.hpa.com.au

**********************************************************************

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20071114/6abd9679/attachment.html