interesting problem in QTP

Arthur Kogan akogan@westpac.com.au
Thu, 25 Jun 1998 15:43:18 +1000


Hi all,

well... this must really be my lucky day!!!

I made the change splitting one request into two and adding JUST ONE EXTRA SUBFILE.
The amount of extra code was insignificant.

And what do I get for my efforts?

An error message at the end of compilation saying:

"Too many files declared for this run. QTP ending."

Sometimes it is just not worth getting up in the morning!!!

I guess I will have to split this QTP into two after all (which is probably not
altogether a bad thing, since it currently contains about 2,200 lines of code).

Regards and thanks to all the people that responded to my call for help,

Arthur Kogan
Westpac Financial Services
Sydney, Australia
Open VMS (ALPHA)
RMS files
Powerhouse 7.10F4



Arthur Kogan wrote:

> Hi Peter,
>
> thanks a lot for your response.
>
> I think the following approach, that you have suggested, is probably the best:
>
> > Another possibility is to summarize the 2 paired transactions into one
> > transaction in another prepass request, before the validation step.
>
> I will investigate this possibility, possibly creating another subfile of
> summarized transactions and using it to flag VALID / INVALID, then using the
> original subfile (containing separate transactions) to actually apply the VALID
> transactions to the members' accounts.
>
> Once again thanks a lot for your response.
>
> Regards,
>
> Arthur Kogan
> Westpac Financial Services
> Sydney, Australia
> Open VMS (ALPHA)
> RMS files
> Powerhouse 7.10F4
>
> Peter Bell (Tel 6230 5585) wrote:
>
> > Arthur
> >
> > I noticed that the "reverse tax" transaction occured before the "reverse
> > contribution" transaction, I can see how this may have been generated but
> > it does not reflect the actual timing of transactions. Perhaps the timing
> > factor may be useful to examine.
> >
> > You are doing a prepass to determine the validity of each transaction
> > within a transaction set for an account number. Flagging all records
> > needing detailed processing may help define the technical problem to
> > overcome, I see a record structure something like
> >
> > account number key
> >   transaction 1  valid
> >   transaction 2  invalid
> >   transaction 3  invalid
> >   transaction 4  valid
> >
> > you could write to a subfile all the records for an account number that are
> > causing the problems then use quick to perform any looping through multiple
> > qtp passes. Using a subset of the overall transactions will offset the
> > multiple calls to qtp from quick for the looping process.
> >
> > Another possibility is to summarize the 2 paired transactions into one
> > transaction in another prepass request, before the validation step.
> >
> > It is a difficult one and may require some more detailed analysis.
> >
> > Pete Bell (peter.bell@oa.hydro.com.au)
> > Powerhouse Consultant
> > Hydro Electric Corporation
> > Hobart Tasmania
> > Powerhouse 7.10E6
> > = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> > Subscribe: "subscribe powerh-l" in message body to majordomo@lists.swau.edu
> > Unsubscribe: "unsubscribe powerh-l" in message to majordomo@lists.swau.edu
> > powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
> > 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
powerh-l@lists.swau.edu is gatewayed one-way to bit.listserv.powerh-l
This list is closed, thus to post to the list, you must be a subscriber.