Maintaining a read chain?

[Fry, Mark]

Hi Martyn,

The problem you have is that the screen you are calling (TRAX233) is
inheriting the QUERY transaction from screen TRAX1424, and using the QUERY
transaction for the gets on TAB_ERRORS.  Since TAB_ERRORS is a local file
(ie. it is not being passed in from the screen above), it is making the
QUERY transaction locally-active to the screen.  By default, QUICK will
commit a locally-active QUERY transaction when you change mode or exit the
screen (unless you are passing a file into the screen).  When you get back
to screen TRAX1424, you will find that your sequential read-chain has been
broken because the QUERY transaction was committed.  This is the root of
your problem.  

There are three ways you could change this behaviour:

1. Declare the existing QUERY transaction on screen TRAX233 and change its
commit point.
eg. Add the statement  TRANSACTION QUERY INHERITED NOCOMMIT
2. Declare a new QUERY transaction on screen TRAX233.
      eg. Add the statement   TRANSACTION QUERY READ ONLY
3. Pass a file from screen TRAX1424 to screen TRAX233 to prevent the QUERY
transaction from being committed.

With solution 1 above, you are using the existing transaction, so you don't
invoke the overhead of a separate database attach, and starting and
committing a new QUERY transaction.  Solution 2 would appear to work just as
well to the user, but in fact the new QUERY transaction would need a new
attach to RDB, and so would be less efficient than 1.  Solution 3 means
passing a (possibly large) record buffer between the screens (and changing
the coding of both screens), so is more work for QUICK and for the
programmer.

My advice is to add those 4 extra words in solution 1 to screen TRAX233.
That should be all you need to do.

Hope that helps,

Mark Fry
Cognos Limited
email: Mark.Fry@Cognos.com

 -----Original Message-----
From: 	Thomson, Martyn EDUC:EX [mailto:martyn.thomson@gems1.gov.bc.ca] 
Sent:	03 March 2000 18:47
To:	'POWERHOUSE Listserv'
Subject:	Maintaining a read chain?

I have a simple one-record screen to maintain a SUSPENSE table. Access can
be sequential so user can page through the records. Each record has a list
of error codes, and by entering "ERR"  in the Actionbar a design procedure
executes a "RUN SCREEN" command, passing the list of codes to a slave screen
to display error messages from a designer file.
My problem is, when user exits the error screen and returns to the main
screen, the read chain is lost and PageDown just starts over from the first
record, rather than displaying the next record.  The slave screen must be
committing the Query transaction. How can I prevent that and retain the read
chain in the main screen?
I've tried using the TRANSACTION stmt to try to isolate the files in the two
screens; I've tried declaring the primary file as an aliased secondary, but
can't find a combination that works.
The Dictionary Transaction Model is Optimistic and dual i.e. Entry/Find
Model: Consistency, Select Model: Concurrency

Here's the relevant code - 

SCREEN TRAX1424 ACTIVITIES FIND, CHANGE, DELETE 
FILE SUSPENSE IN TRAX PRIMARY
ACCESS VIAINDEX KEY_SUSP_MARK_RESP_OCR_NO REQUEST STUD_NO
ACCESS SEQUENTIAL 
...
PROCEDURE DESIGNER ERR
 BEGIN
     RUN SCREEN XTR$EXEC:TRAX233 PASSING T_ERR_CODES MODE F
 END

SCREEN TRAX233 SLAVE RECEIVING T_ERR_CODES
FILE TAB_ERRORS IN TRAX DESIGNER
...
PROCEDURE INITIALIZE
BEGIN
;display first 15 error codes/messages; if more, prompt user to hit RETURN
for next page
  LET T_REC_CNT=1
  FOR 15
  BEGIN
     GET TAB_ERRORS VIAINDEX ERR_CODE USING T_ERR_CODES[T_REC_CNT * 3 -2:3]
OPT
     IF ACCESSOK
     THEN BEGIN
        LET T_ERR_MSG = ERR_MSG OF TAB_ERRORS
        DISPLAY T_ERR_MSG
     END
     LET T_REC_CNT=T_REC_CNT + 1
  END

Is what I'm trying to do possible? All comments/suggestions welcome.
I'm using 7.10G1 for OpenVMS, and Rdb 7.0
Martyn Thomson
Ministry of Education, BC
 

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
This list is closed, thus to post to the list, you must be a subscriber.