QUICK using unexpected index

[Jeroen van der Linde]

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/fa762526/attachment.html