Aliasing the file will give you a second GET chain but you'll have to
OPEN the file with a new file number to run two chains in parallel.
The way GET is processed depends massively on where in the code -
specifically which procedure - you're calling it from.
Subscribe to [log in to unmask] for more fun. In fact, I've
taken the liberty of cross-posting this question to them
-----Original Message-----
From: HP-3000 Systems Discussion [mailto:[log in to unmask]] On
Behalf Of Roy Brown
Sent: 22 June 2008 19:57
To: [log in to unmask]
Subject: [HP3000-L] QUICK question on GET
I'm looking at a 15-year-old bespoke shop floor reporting system,
written in Cognos QUICK. Apart from Y2K changes, it has barely been
touched over the years, and hasn't needed to be.
However, now it needs to be interfaced to Oracle Manufacturing, its
quirks have been promoted to the status of bugs, and I have been tasked
with fixing them.
One thorny issue turns on us unexpectedly falling off the end of the
routings chain :-(
So; does anyone know, or can point me to a resource, that gives more
information about GET in QUICK than the QDESIGN manual does?
I'm thinking specifically about its interaction with the Image 'current
record' consideration. This term is not to be found in the QDESIGN index
:-(
For an Image Detail dataset, as I interpret the manual, GET will return
one record from that detail dataset ('return' rather than 'retrieve', as
a SELECT will cause it to read multiple records to find one that you
want).
So, AFAICS, if you issue the same GET again, accessing the chain via the
same key field and key value, and no SELECT is in force, it will get the
next record in the chain.
My question, though, is when *won't* it get the next record? i.e. what
will make it issue a new Image FIND?
As far as I can tell, the following:
(i) referencing a different key field
(ii) referencing a different key value
(iii) using the UNIQUE option on the GET
(iv) using an ALIAS for the dataset on a second OPEN
(v) using an ALIAS for the dataset anyway
(i) -(ii) seem to be implied, (iii) is documented, (iv) is deduced from
what I know of how Image behaves, and (v) has been found by experiment
(at least, I think I found that, but maybe I haven't caught all the
subtleties. From the manual, you might think that all having an ALIAS
does is give you a second record area, but it looks like it resets GET.
Or does it?).
From the manual's discussion of PUT, it seems fairly clear that QUICK
is
keeping record numbers someplace internal, and that when I PUT (update)
a record in a dataset, and another from an ALIAS for it, I don't need to
worry about where the current record pointer is, as QUICK takes care of
it all for me.
And I'm sure it does that on GET, also, so I figure I can probably
intermingle GETs on a detail dataset by one key/value with GETs on
another key/value (and even the same physical value, as long as QUICK
sees then coming from different variables) with impunity.
But somewhere this assumption doesn't seem to be applying, and if you
can help me figure out where, I'd be very grateful.
Roy
--
Roy Brown 'Have nothing in your houses that you do not know to be
Kelmscott Ltd useful, or believe to be beautiful' William Morris
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
* Please Note : This message was received from the Internet *
_____________________________________________________________
__________________________________________________________________
Visit Schroders Talking Point for market news and expert views http://www.schroders.com/talkingpoint
This message might contain confidential information. If it has been sent to you in error please do not forward it or copy it or act upon its contents, but report it to [log in to unmask]
Schroders has the right lawfully to record, monitor and inspect messages between its employees and any third party. Your messages shall be subject to such lawful supervision as Schroders deems to be necessary in order to protect its information, its interests and its reputation.
Schroders prohibits and takes steps to prevent its information systems from being used to view, store or forward offensive or discriminatory material. If this message contains such material please report it to [log in to unmask]
Schroders does not normally accept or offer business instructions via email unless prior agreements are in place. Any action that you might take upon this message might be at your own risk.
Schroder Investment Management Limited
31 Gresham Street
London EC2V 7QA
Authorised and regulated by the Financial Services Authority. Schroder Investment Management Limited is entered on the FSA register under the following register number: 119348
Registered Office
31 Gresham Street
London EC2V 7QA
Registered number 1893220
VAT registration number 243 8687 30
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
