{Disarmed} RE: Stupid question about Primary and Secondary

Wed Nov 14 08:41:50 CST 2007

Fernando,

You could code your find procedure and remove the optional or if you're in
the land of databases you could create a cursor?

Best Regards,

Dave

  _____  

From: powerh-l-bounces+daveb=thyme-it.ie at lists.sowder.com
[mailto:powerh-l-bounces+daveb=thyme-it.ie at lists.sowder.com] On Behalf Of
Ken Langendock
Sent: 14 November 2007 14:25
To: fernando.olmos at hpa.com.au; powerh-l at lists.sowder.com
Subject: {Disarmed} 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-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC45B9
843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000660A0500
00/www.hpa.com.au> MailScanner has detected a possible fraud attempt from
"outbind:" claiming to be 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-000000004873297C6F02D34791376BCD02053396070089F66260EA86FC45B9
843CB9AE160C240000003C72B40000B1FC7253EE1378408169587124093AAC000000660A0500
00/www.hpa.com.au> MailScanner has detected a possible fraud attempt from
"outbind:" claiming to be 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/546ebfeb/attachment-0001.htm