Maintaining a read chain?

[Thomson, Martyn EDUC:EX]

Thanks Blue - your suggestion worked great. 
To get the records to display immediately in the called screen I had to
specify "MODE NULL" on the RUN SCREEN and declare a Designer file alias of
the Primary file for the Initialize procedure to read using the list of
keys, but hey, it works!

I also found that it would work as a slave screen called in find mode
(without a TRANSACTION stmt) so long as I passed a file down and declared it
as a master.  but your method is better.
Thanks again,
Martyn


> -----Original Message-----
> From: Robert J.M. Edis [mailto:robert.edis@creatcomp.com]
> Sent: March 3, 2000 12:44 PM
> To: 'powerh-l@list.swau.edu'
> Subject: RE: Maintaining a read chain?
> 
> 
> G'day Martyn
> 
> First of all, your "RUN SCREEN " is calling a subscreen, not 
> a slave screen.
> Slave screens have a MASTER file passed to them, usually the 
> PRIMARY file of
> the calling screen.  Remove the 'SLAVE' from the SCREEN 
> statement as this
> will automatically associate the subscreen's query 
> transaction with the
> calling screen.
> 
> By default, PowerHouse with Oracle Rdb generates two transactions per
> screen, a query and an update.  The query trasnaction is 
> being inherited by
> you subscreen.  The default commit is mode and when this 
> changes on your
> subscreen the query transaction is commited.  The result 
> being that when you
> get back to the calling screen the query transaction is 
> restarted and your
> read chain is broken.
> 
> Declare a new QUERY transaction on the subscreen and this 
> should prevent the
> calling screen's query transaction from being reset.
> 
> It's been a while since I worked with Rdb but I believe this 
> is basically
> it.
> 
> Regards,
> 
> Blue 
> 
> -----Original Message-----
> From: Thomson, Martyn EDUC:EX
> To: 'POWERHOUSE Listserv'
> Sent: 3/3/00 1:47 PM
> 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.
> 
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
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.