hi ALL:
QUICK will read down a detail chain if
the QUICK file type is PRIMARY, DETAIL, DELETE or DESIGNER.
The DESIGNER must be used within a WHILE RETREIVING loop
or qualified with a SELECT option.
I too dealt with a problem of chaining
"unexpectedly falling off the end of the routings chain."
I was getting and error that forward and backward pointers
were not matching.
This happenned in FIND mode. It did not occur often.
It usually occurred when some other user added a record to
the end of the chain.
To get around this:-
I back tracked on the detail chain.
The following technique may have problem if the chain has a
sort item and other user had inserted a record in the chain
before last one on our screen.
i.e.
Temp T_LOC integer size 4 initial value -1 reset at mode
FILE X OCCURS 10
FILE X DES ALIAS X_DES
ACCESS VIA KEY USING T_KEY BACKWARDS
SELECT IF T_LOC = RECORDLOCATION of X_DES
PROCEDURE POSTPATH
BEGIN
LET T_KEY = <key value from PATH>
END
PROCEDURE FIND
BEGIN
IF T_LOC > -1
THEN GET X_DES OPTIONAL
rest of find procedure
PROCEDURE POSTFIND
BEGIN
LET T_LOC = -1
FOR 10 ; the occurence of X
BEGIN
IF NOT NEWRECORD of X
THEN LET T_LOC = RECORDLOCATION of X
END
END
> Subject: RE: [HP3000-L] QUICK question on GET> Date: Sun, 22 Jun 2008 23:40:19 +0100> From: [log in to unmask]> To: [log in to unmask]; [log in to unmask]> CC: [log in to unmask]> > 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> > -- > = = = = = = = = = = = = = = = = = = = = = = = = = = = => Mailing list: [log in to unmask]> Subscribe: "subscribe" in message body to [log in to unmask]> Unsubscribe: "unsubscribe <password>" in message body to [log in to unmask]> http://lists.sowder.com/mailman/listinfo/powerh-l> This list is closed, thus to post to the list you must be a subscriber.> Add 'site:lists.sowder.com powerh-l' to your search terms to search the list archive at Google.
_________________________________________________________________
Find hidden words, unscramble celebrity names, or try the ultimate crossword puzzle with Live Search Games. Play now!
http://g.msn.ca/ca55/212
* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
|
