refresh field value
Lorry Litman
LLitman@exchange.hsc.mb.ca
Fri, 11 Jun 2004 10:22:16 -0500
This is a multi-part message in MIME format.
--=_Part_730db69a$a7dc$4f92$b4cb$485982205753
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable
Hi Peter, thanx for your reply. I'll stick with what I've got since it se=
ems
to be working fine without any ill affects. Lorry.
-----Original Message-----
This e-mail and/or any documents in this transmission is intended for the=
address(s) only and may contain legally privileged or confidential infor=
mation. Any unauthorized use, disclosure, distribution, copying or dissem=
ination is strictly prohibited. If you receive this transmission in error=
, please notify the sender immediately and return the original.
--=_Part_730db69a$a7dc$4f92$b4cb$485982205753
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
From: Peter Bateman [mailto:pfbcs@hotmail.com]
Sent: Friday, June 11, 2004 8:42 AM
To: powerh-l@lists.sowder.com
Subject: RE: refresh field value
MIME-Version: 1.0
Lorry:
>From: Lorry Litman <LLitman@exchange.hsc.mb.ca>
>To: 'Peter Bateman' <pfbcs@hotmail.com>
>Subject: RE: refresh field value
>Date: Thu, 10 Jun 2004 11:59:08 -0500
>
>Hi Peter,
>
>Why would I need to commit the query transaction?
>How would I know?
>Query is the default transaction name for query. I have defined it for
>query
>and process. This is something I've almost always used on reference files
>so
>the update transaction doesn't start on lookups of the field statement.
>If I have to commit the transaction, I suspect I would probably want to
>create a separate transaction for that one reference file.
>
I can understand that you don't want your PUTs to be translated
to actions in a long UPDATE transaction. However, in this case you
want post start of QUERY changes to be diisplayed.
I woulld do the lookups in the UPDATE transaction which I believe
should be commited after the UPDATE procedure in the subscreen.
Just to sure you could put the COMMIT UPDATE statement just
before your get after the RUN SCREEN.
Use PUSH RETURN rather than the RETURN verb to get out of the subscreen.
The difference is the RETURN verb returns to the calling screen without
completing the procedure iit is in. Whereas ther PUSH RETURN allows
the end of procedure process to complete including commit the UPDATE
transaction.
Regards,
Peter Bateman
-----Original Message-----
--=_Part_730db69a$a7dc$4f92$b4cb$485982205753
Content-Type: message/rfc822
Content-Transfer-Encoding: 8bit
From: Peter Bateman [mailto:pfbcs@hotmail.com]
Sent: Thursday, June 10, 2004 10:22 AM
To: powerh-l@lists.sowder.com
Subject: RE: refresh field value
MIME-Version: 1.0
Lorry:
You may have to commit your transaction before trying your get after the
run screen.
i.e. COMMIT QUERTY
GET .
>From: Lorry Litman <LLitman@exchange.hsc.mb.ca>
>To: "PowerHouse listserver (E-mail)" <powerh-l@lists.sowder.com>
>Subject: RE: refresh field value
>Date: Thu, 10 Jun 2004 08:34:04 -0500
>
>Thank-you for the ideas. The qdesign books seemed to indicate that UNIQUE
>could only be used with primary,secondary,detail files. I tried it anyway
>on
>the reference file, it didn't give me an error, but, it also didn't seem to
>change anything.
>
>The following seems to work ok.
>
>File section
> file F reference &
> transaction query for query,process
> access via ....
> using ...
>
>Field section
> 02 field A of F DISPLAY
> field B of F DISPLAY
> field C of F DISPLAY
>
>Procedure section
> procedure designer 02
> begin
> run screen B passing temp...
> get file F via... using... optional
> display field A of F
> display field B of F
> display field C of F
> end
>
--=_Part_730db69a$a7dc$4f92$b4cb$485982205753--