Why is this happening?

[fernando.olmos at hpa.com.au]

Unfortunately that didn't work... and I expect it wouldn't because my
understanding is that the ITEM statements, following an OUTPUT (or a
temporary?) will related to that OUTPUT statement, hence that is why if
I don't qualify some items, they automatically get initialised to the
value in the OUTPUT table from values in the subfile.

Thanks anyway.

Something odd though. It does work if I remove the consignment number in
the subfile! Go figure!


-----Original Message-----
From: mcl_systems at telus.net [mailto:mcl_systems at telus.net] 
Sent: Monday, 30 October 2006 1:41 PM
To: Fernando Olmos
Subject: Re: Why is this happening?


Hi Fernando,

I think the problem will be resolved if you qualify your ITEM statement 
on the output file as follows:

item despatch_no of  despatch_actuals   = t_next_despatch_no


My thinking is that the 'despatch_no' in the OUTPUT file is being 
initialized to the same value in the subfile and that's the item you're 
updating. Anyway give it a try and see if it works.


Regards,


Michael Lee
MCL Systems Inc.


fernando.olmos at hpa.com.au wrote:

>Hi everyone...
>
>I have a subfile with the following columns and rows ...
>
>  Consignment       Order  Despatch  Despatch    Despatch    FPOS
>T_NEXT_DESPATCH_NO
>      No             No       No       Flag        Qty       DOT
>                                                             Flag
>
>  7280072119270    859468               C                 1   N
>5
>  7280072119271    859469               C                12   N
>5
>  7280072119273    859469               C                 1   N
>6
>  7280072119272    859474               H                20   N
>1
>  7280072119274    859474               C                 1   N
>2
>  7280072119274    859474               O                 8   N
>3
>  7280072119274    859474               C                 2   N
>4
>
>I have the following QTP code using the above subfile ...
>
>access *mipss1200j
>
>output despatch_actuals in isdb add
>item despatch_no     = t_next_despatch_no
>item ...
>..etc..
>
>When I run the program, I get the following results ...
>
>  Consignment       Order  Despatch  
>      No             No       No     
>                                     
>
>  7280072119270    859468     5      
>  7280072119271    859469     5      
>  7280072119273    859469     6      
>  7280072119272    859474     1      
>  7280072119274    859474     4      <-- This should have been 2
>  7280072119274    859474     4      <-- This should have been 3
>  7280072119274    859474     4      
>
>
>The 2nd and 3rd last rows are wrong.
>
>If the above subfile is read in row-by-row, then why is it placing the 
>despatch_no value of '4' on the Order No 859474, when they should have 
>been simply set with '2' and '3' respectively?
>
>There is no sort statement in the request nor any control breaks.
>
>The table I am updating, has an index only on the combination of the 
>"Order No" and "Despatch No" columns. Ignore the Consignment number 
>column because it is not populated into the table.
>
>???
>
>
>Thanks in advance
>**********************************************************************
>IMPORTANT
>The contents of this e-mail and its attachments are confidential and 
>intended solely for the use of the individual or entity to whom they 
>are addressed.  If you received this e-mail in error, please notify the

>HPA Postmaster, postmaster at hpa.com.au, then delete  the e-mail. This 
>footnote also confirms that this e-mail message has been swept for the 
>presence of computer viruses by Ironport. Before opening or using any 
>attachments, check them for viruses and defects. Our liability is 
>limited to resupplying any affected attachments. HPA collects personal 
>information to provide and market our services. For more information 
>about use, disclosure and access see our Privacy Policy at 
>www.hpa.com.au
>**********************************************************************
>
>  
>
**********************************************************************
IMPORTANT
The contents of this e-mail and its attachments are confidential and intended
solely for the use of the individual or entity to whom they are addressed.  If
you received this e-mail in error, please notify the HPA Postmaster, postmaster at hpa.com.au,
then delete  the e-mail.
This footnote also confirms that this e-mail message has been swept for the
presence of computer viruses by Ironport. Before opening or using any
attachments, check them for viruses and defects.
Our liability is limited to resupplying any affected attachments.
HPA collects personal information to provide and market our services. For more
information about use, disclosure and access see our Privacy Policy at
www.hpa.com.au
**********************************************************************