QUICK using unexpected index

Fri Feb 29 14:11:23 CST 2008

To get a definitive answer, we'd have to look in the code. But based on
my understanding of the PowerHouse architecture and "philosophy" is that
the GET on the PRIMARY is basically continuing the read down the chain.

PRIMARY files (and DETAIL files) are special. Remember that we have to
continue the read chain across multiple FIND procedures. So any GET will
normally continue that chained read and do a GET NEXT.

In order to force a re-evaluation of the retrieval mechanism, try adding
UNIQUE to your GET as in 

GET ORDER VIA ORD-NR USING ORD-NR OF ORDER UNIQUE

I have not tried this so I won't guarantee that it will work.

And the reason why a failed GET doesn't receive an error and your
ACCESSOK is false is again the special nature of PRIMARY file retrieval.
I like to call it semi-optional. The retrieval on a PRIMARY or DETAIL
itself is optional but if the GET fails, at least on the PRIMARY, you
don't have a QUICK transaction (not to be confused with a relational
transaction). If a failed GET on the PRIMARY was like other files, you'd
get an immediate error and we'd have trouble retrieving inside a FOR
loop in a cluster among other issues.

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 Bert Onderdijk
	Sent: February 29, 2008 11:16 am
	To: powerh-l at lists.sowder.com
	Subject: QUICK using unexpected index

	Dear Jeroen,

	You may ask Cognos support to work on this but I expect they
will point you to Cognos Consultancy.
	The way you describe it, is to my opinion standard expected
PowerHouse behavior.

	- As you mention, a Select is not a Find;
	- The select on TRANS-REF will build a set of rows that matches
the value you entered;
	- It looks as if your screen is -when retrieving- automatically
going to pre-, update and postupdate;
	- This updates forces an update next, and that means you will
jump tot the next row that matches your selection criterea;
	- And, the select forces that the get in the preupdate is not
done. The accessok will always be false.

	The re-retrieve to get rid of 'Record has been changed since you
found it' is a bit risky. 
	I would try to use different paths and write your own find
procedure to get the data you wish and to make a different get in
preupdate work.

	But, this all said, there are a few others in this mailing list
who are at least able to clarify the why of PowerHouse more then me.
	Yes, write your own find in a complex screen with different type
of files takes time.

	Regards,

	Bert

________________________________

	Van: powerh-l-bounces+f.tang=piramide.nl at lists.sowder.com
[mailto:powerh-l-bounces+f.tang=piramide.nl at lists.sowder.com] Namens
Jeroen van der Linde
	Verzonden: vrijdag 29 februari 2008 10:36
	Aan: powerh-l at lists.sowder.com
	Onderwerp: QUICK using unexpected index

	Dear all,

	I've got a rather strange problem in QUICK. When I do a select
in a quick screen and afterwards a get via a key, quick doesn't use the
key I tell it to use, but seems to use the key in which I entered a
value during my select. I'll try to explain the situation:

	I'm using a primary record with multiple (segmented) indexes:

	Record: ORDERS

	1. Primary (unique) index segment: ORD-NR

	2. Alternate (unique) index segments: CLIENT-NR, ORD-NR

	3. Repeating index, segment: TRANS-REF

	The file is accessed as follows:

	FILE ORDERS PRIMARY CLOSE

	  ACCESS VIA ORD-NR

	  ACCESS VIA CLIENT-NR

	  ACCESS VIA TRANS-REF

	Nothing strange there. Now for the problem:

	Using a Select (not a FIND!) I'll step over the first two
indexes (ORD-NR & CLIENT-NR) and fill in a value in the field TRANS-REF.

	Since this is a very complex screen, in the PREUPDATE procedure
the primary file is retrieved again to avoid 'Record has been changed
since you found it'.

	The retrieval command is simple:

	GET ORDER VIA ORD-NR USING ORD-NR OF ORDER

	Since this record should always be there, no optional has to be
used. But... when I check out the 'accessok' after the GET statement, it
is false! The record absolutely still exists (no delete has been done)
and when looking at the content of the file ORDERS, after the GET
statement, some other (random?) record is displayed. It seems that Quick
doesn't use my programmed index, but instead uses the index of the field
in which I put my select value.

	Does anybody recognizes this problem and, more important, does
anybody has a solution for this problem, without:

	- adding new indexes

	- putting 'NOSELECT' on the TRANS-REF field

	Thanks in advance for your time and help,

	Jeroen van der Linde

	-------------------------------------------------

	Powerhouse version: 7.10G1

	OpenVMS version: 7.3-1

	All files are RMS files

	-------------------------------------------------

     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/20080229/174b4326/attachment.html