QUICK using unexpected index

[Bert Onderdijk]

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.sowder.com/pipermail/powerh-l/attachments/20080229/8edb4840/attachment.htm