Erratic QTP

[Rick Hill]

Is the data needed in *QTEMP/T5731011 at all dependent on earlier 
requests?  It could be that running this as two separate programs fixes 
the problem because the data is getting committed by default at the end 
of the RUN in the first one - hence the 2nd program with the code that 
writes the rec can now see the data it needs.

If this could be it, try putting "COMMIT AT REQUEST" at the top of your 
original version with the multiple requests. 

good luck!

Rick Hill

> 
> 
> Well Chris the "item d-qty-issue subtotal glu reset at sort-field"
> statement didn't
> work either.  I split the routine out into its own program and that
> works so I have a solution albeit not
> a clean one.  Sure is peculiar.
> Thanks to all for the help.  This list is a great resource!
> George
> 
> 
> |------------->
> |(Embedded    |
> |image moved  |
> |to file:     |
> |pic07933.pcx)|
> |             |
> |------------->
>   >-------------------------------------------------------------------
-|
>   |"Chris Sharman" 
<chris.sharman@ccagroup.co.uk>                      |
>   |01/24/2003 03:05 
AM                                                 |
>   >-------------------------------------------------------------------
-|
> 
> 
> 
> To:   George J. Wen/NB/USFAC/ABB@ABB_US01, powerh-l@lists.swau.edu
> cc:
> Subject:  RE: Erratic QTP
> 
> Security Level:?         Internal
> 
> 
> 
> 
> > A QTP program I have has multiple requests.  I have one request from
> > within the program that
> > produces different results when run separately by itself.  A user
> > brought to my attention that a
> > particular record was not updated (via a subsequent report).  So I 
ran
> > the program in session
> > and sure enought the record in question was not being updated but 
when
> I
> > split the request out
> > to isolate the code so only the request in question here would run 
it
> > ran correctly and updated
> > the record the user called about .  Any ideas?
> > I'm on 6.07 as/400 and that may or may not matter.  I can try
> splitting
> > out the programs so this
> > request is on it's own but I wonder if there's another answer?
> Here's
> > the code:
> >
> > Request GetQtyIssued
> >
> >
> >
> > Access *QTEMP/T5731011 &
> >    link QAOMCU, "II", QALITM viaindex F0911L1 &
> >       to GLMCU, GLDCT, GLEXR of I0911
> >
> >
> > define SORT-FIELD char*50 = QAOMCU + GLDCT + QALITM
> > Sort on SORT-FIELD
> >
> > temp D-QTY-ISSUE float*8
> > item D-QTY-ISSUE = D-QTY-ISSUE + GLU
> >
> > Output T5731011 Update at SORT-FIELD on Errors Report
> >    item ISSUE-NBR  final GLDOC
> >    item QTY-ISSUED final D-QTY-ISSUE
> >    item D-QTY-ISSUE reset at SORT-FIELD
> >    item PO-TYPE    final GLDCT
> > Go
> 
> Is the output the same file as the primary input, or not ?
> I guess not, since there's no "*".
> 
> Your d-qty-issue statements are a little odd - the 'normal' syntax 
would
> be:
> 
> item d-qty-issue subtotal glu reset at sort-field
> although I've no reason to think the construct you have is faulty.
> You've got "on errors report". Does it report errors ?
> 
> To diagnose, trying keeping the subfile, and checking it, to see 
whether
> the
> record in question is included, or omitted by some problem with an
> earlier
> request.
> 
> Chris
> 
> 
> 
> ----------------------------------------------------------------------
-
> 
> Any views expressed in this message are those of the sender and not
> necessarily those of CCA Group.  The unauthorized use, disclosure,
> copying or alteration of this message is forbidden.  The contents of
> this message may be confidential and/or privileged, copyright CCA 
Group
> and are intended solely for the use of the individual or entity to 
whom
> they are addressed.  Whilst this message has been scanned, CCA Group
> cannot guarantee that it is virus free or compatible with your systems
> and accepts no responsibility for any loss or damage arising from its
> use. The recipient is advised to run their own anti-virus software. If
> you receive this message in error please contact
> postmaster@ccagroup.co.uk immediately, destroy any copies and delete 
it
> from your computer systems.
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to
> powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
> powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a 
subscriber.
> 
> 
> 
> 

-- 
CoreComm Webmail. 
http://home.core.com