QUICK using unexpected index

Mon Mar 3 14:10:45 CST 2008

        Hi Jeroen:

              I assume you meant ORDERS not ORDER in your GET.

              Your GET and my technique assume that whatever is on file
              is what we want to start the UPDATE. i.e. if someone else has changed
              the ORDERS record after we had executed the FIND procedure then
              that is ok we just use their data.

              I would set up a designer alias of the primary. say DES_ORDERS

               In the UPDATE
                LOCK ORDERS  
               GET DES_ORDERS via ORDER etc
   ;            Copy the data from the DES_ORDERS  buffer to the  
   ;            ORDERS  buffer                        
               PUT ORDERS
            UNLOCK ORDERS
If you still get the message 
'Record has been changed since you found it'.
Then you are changing something in the UPDATE. SUM INTOs and COUNT INTOs
are sometimes the culprit. 
         Regards,
         Peter Bateman

Subject: RE: QUICK using unexpected indexDate: Fri, 29 Feb 2008 15:11:23 -0500From: Bob.Deskin at cognos.comTo: powerh-l at lists.sowder.com

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 OnderdijkSent: February 29, 2008 11:16 amTo: powerh-l at lists.sowder.comSubject: 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 LindeVerzonden: vrijdag 29 februari 2008 10:36Aan: powerh-l at lists.sowder.comOnderwerp: 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/20080303/b5b36af2/attachment.htm