Stupid question about Primary and Secondary

Thu Nov 15 17:26:39 CST 2007

Waiting in anticipation for the next version with the ability for us to
keep the 4GL intact and reduce the need to modify code where it should
be needed (ie: make Powerhouse a 3GL!).    ;)

Kind regards, 

--- 
Fernando Olmos 
Senior Analyst Programmer 
HPA - A Salmat Company
Direct: 02 9311 5411
Fax: 02 9311 5166
Mobile: 0434 879 784 

<outbind://72-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC
45B9843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000
660A050000/www.hpa.com.au> www.hpa.com.au 

-----Original Message-----
From: Bob.Deskin at Cognos.COM [mailto:Bob.Deskin at Cognos.COM] 
Sent: Thursday, 15 November 2007 1:53 AM
To: Ken at Langendock.com; Fernando Olmos; powerh-l at lists.sowder.com
Subject: RE: Stupid question about Primary and Secondary

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 

<outbind://72-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC
45B9843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000
660A050000/www.hpa.com.au> 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 

<outbind://72-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC
45B9843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000
660A050000/www.hpa.com.au> 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