New PowerHouse Documentation

Mon Jul 9 17:51:32 CDT 2007

At my current age, I'm surprised I remember anything, but in this
case... I do!

It is exactly as you were supposing Bob. The original example was a
substructure of an item named FULLNAME that was logically LASTNAME
concatenated to FIRSTNAME. 

I was example, as I recall, was only to show what the SILENT option did.
The FULLNAME field didn't show up on the screen but the EDIT verb in the
generated ENTRY procedure executed the Lookup (and I presume any other
dictionary related edits on FULLNAME).

How FULLNAME got magically transmogrified into EMPLOYEE_NUMBER is beyond
me. I can't see how the current version would even work since there
doesn't appear to be any way to enter a value for EMPLOYEE_NUMBER. As
Bob said, someone who didn't understand the original intent probably
edited it because they didn't think it was necessary to restructure
items anymore.

Matt 

________________________________

From: powerh-l-bounces+matt.ohmes=cognos.com at lists.sowder.com
[mailto:powerh-l-bounces+matt.ohmes=cognos.com at lists.sowder.com] On
Behalf Of Deskin, Bob
Sent: Monday, July 09, 2007 1:26 PM
To: Joe Boyle; Ken Langendock; powerh-l at lists.sowder.com
Subject: RE: New PowerHouse Documentation

Joe, thanks for this. No one's ever mentioned this to me that I can
recall. I don't know what the history is but I'll bet that the original
had something like FULLNAME redefined or substructured by FIRSTNAME and
LASTNAME. Once you entered the first and last names, you want to do a
lookup on the whole thing to ensure uniqueness. The original was
probably done for IMAGE. Since there are no redefinitions or
substructures in relational, it was probably changed at that time, and
by someone who didn't understand the original meaning.

I'll add this to the list to be fixed in the next release.

Thanks

Bob

	-----Original Message-----
	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 Joe Boyle
	Sent: June 25, 2007 2:45 PM
	To: 'Ken Langendock'; powerh-l at lists.sowder.com
	Subject: RE: New PowerHouse Documentation

	I was simply responding to Bob's comment ( reproduced below )
perhaps it is now time to make this syntax meaningful or remove it.

	If you spot any issues, please let me know. 

	Bob 

	In addition to Lee's comments, I imagined that the surname must
be a repeating index which means you would always get the same
employeenumber returned for btree type data files, or a randomly varying
employeenumber for RDB tables. 

	There are so many permutations that could be created by adding
syntax, or simply imagining a scenario not established in the example.

	The request for an answer was a tad rhetorical, but there may
have been someone that had a plausible one - it seems not.

________________________________

	From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On
Behalf Of Ken Langendock
	Sent: 25 June 2007 13:07
	To: powerh-l at lists.sowder.com
	Subject: RE: New PowerHouse Documentation

	Are you serious? Are you still looking for an answer?

	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 Joe Boyle
	Sent: June 24, 2007 7:18 AM
	To: 'Deskin, Bob'; powerh-l at lists.sowder.com
	Subject: RE: New PowerHouse Documentation

	Hi Bob,

	The stuff below has always confounded me, and I am staggered to
see it still included in the Qdesign reference Documentation. I first
saw this in the early 90's after being on my first PH training course
and assumed that I was not familiar enough with PH to understand it - 15
years later and I still don't understand it.

	In the following example, an employees file is used to develop a
screen that contains an

	employee's surname and first name. The field employee-NUMBER is
a silent field that is used for

	lookup only, and QDESIGN generates an edit verb for this field
in the default entry procedure.

	The EDIT verb causes QUICK to perform a lookup, ensuring that an
EMPLOYEENUMBER for

	the specified LASTNAME and FIRSTNAME exists.

	> SCREEN EMPNAMES

	> FILE EMPLOYEES PRIMARY

	> FIELD LASTNAME OF EMPLOYEES REQUIRED NOCHANGE

	> FIELD FIRSTNAME OF EMPLOYEES

	> FIELD EMPLOYEENUMBER OF EMPLOYEES &

	> SILENT LOOKUP ON EMPLOYEES

	> 

	> PROCEDURE ENTRY

	> BEGIN

	> ACCEPT LASTNAME OF EMPLOYEES

	> ACCEPT FIRSTNAME OF EMPLOYEES

	> EDIT EMPLOYEENUMBER OF EMPLOYEES

	> END

	> BUILD

	I am sharing this with the list just in case anyone can tell me
how this works ?

________________________________

	From: powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com
[mailto:powerh-l-bounces+atla38=dsl.pipex.com at lists.sowder.com] On
Behalf Of Deskin, Bob
	Sent: 22 June 2007 22:14
	To: powerh-l at lists.sowder.com
	Subject: New PowerHouse Documentation

	I've just posted the updated documentation to the PowerHouse Web
site at http://powerhouse.cognos.com <http://powerhouse.cognos.com>  

	These books should be up to date as of 3.4E/8.4E. We've also
corrected most of the outstanding documentation issues. The rest will be
looked at for the next version.

	If you spot any issues, please let me know. 

	Bob 

	     This message may contain privileged and/or confidential
information.  If you have received this e-mail in error or are not the
intended recipient, you may not use, copy, disseminate or distribute it;
do not open any attachments, delete it immediately from your system and
notify the sender promptly by e-mail that you have done so.  Thank you. 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20070709/4f481c7b/attachment-0001.html