JohnDanter2
VIP Member
Hi all
We have just upgraded from 9.0 to 9.2 and came across some weird issues with Ship Confirm, R42500 > R47500. It basically only did half the job.
I tracked it down to a begin / end transaction setup in the End Section of R47500 which failed when calling the Ship Con BSFN due to an error in F3462 (same transaction bubble as the Ship Con BSFN.
The error was due to a new index in 9.2 that used to be a unique constraint in F3462 on ITM MCU PDDJ but is now moved to ITM MCU PDDJ SHAN.
How could this have been missed in the upgrade process if we did everything correctly (moving the data then running thre R98 711 713 jobs to gen indexes as per E1 metadata specs??
Ship Confirm End Doc calls internal BSFN N3401380 to write to F3462.
The object that writes the F3462 is BSFN, F3462UpdateForcstShpmntSummyRec N3401380
So in the log this select failed (as at the time it wasn't there)
SELECT * FROM PRODDTA.F3462 WHERE ( MBITM = 6178889.000000 AND MBMCU = ' 908' AND MBSHAN = 203487.000000 AND MBPDDJ = 122321 )
Then it tries to insert this
INSERT INTO PRODDTA.F3462 (MBITM, MBLITM, MBAITM, MBMCU, MBCO, MBUORG, MBPDDJ, MBUPMJ, MBUSER, MBJOBN, MBPID, MBTDAY, MBUKID, MBSHAN) VALUES (6178889.000000,'6178889 ','6178889 ',' 908','00908',12.000000,122321,122321,'E1PDSCHED','SCS-A-BATP','N4200790',220757.000000,1011210.000000,203487.000000)
And failes due to unique constraint (old 9.0 specs on the 3 columns not the new 4)
In 9.0 N3401380 uses index 1 to check F3462 (using ITM MCU and PPDJ) If it finds one it updates else inserts
In 9.2 N3401380 uses index 5 to check F3462 (Using ITM MCU PPDJ and now SHAN). If it finds one it updates else inserts. It's failing to insert and that is because ITM MCU PDDJ as still a unique constraint as per the OLD 9.0 specs
What could we have missed and has this happened to anyone else? As it must have
Thanks
John
We have just upgraded from 9.0 to 9.2 and came across some weird issues with Ship Confirm, R42500 > R47500. It basically only did half the job.
I tracked it down to a begin / end transaction setup in the End Section of R47500 which failed when calling the Ship Con BSFN due to an error in F3462 (same transaction bubble as the Ship Con BSFN.
The error was due to a new index in 9.2 that used to be a unique constraint in F3462 on ITM MCU PDDJ but is now moved to ITM MCU PDDJ SHAN.
How could this have been missed in the upgrade process if we did everything correctly (moving the data then running thre R98 711 713 jobs to gen indexes as per E1 metadata specs??
Ship Confirm End Doc calls internal BSFN N3401380 to write to F3462.
The object that writes the F3462 is BSFN, F3462UpdateForcstShpmntSummyRec N3401380
So in the log this select failed (as at the time it wasn't there)
SELECT * FROM PRODDTA.F3462 WHERE ( MBITM = 6178889.000000 AND MBMCU = ' 908' AND MBSHAN = 203487.000000 AND MBPDDJ = 122321 )
Then it tries to insert this
INSERT INTO PRODDTA.F3462 (MBITM, MBLITM, MBAITM, MBMCU, MBCO, MBUORG, MBPDDJ, MBUPMJ, MBUSER, MBJOBN, MBPID, MBTDAY, MBUKID, MBSHAN) VALUES (6178889.000000,'6178889 ','6178889 ',' 908','00908',12.000000,122321,122321,'E1PDSCHED','SCS-A-BATP','N4200790',220757.000000,1011210.000000,203487.000000)
And failes due to unique constraint (old 9.0 specs on the 3 columns not the new 4)
In 9.0 N3401380 uses index 1 to check F3462 (using ITM MCU and PPDJ) If it finds one it updates else inserts
In 9.2 N3401380 uses index 5 to check F3462 (Using ITM MCU PPDJ and now SHAN). If it finds one it updates else inserts. It's failing to insert and that is because ITM MCU PDDJ as still a unique constraint as per the OLD 9.0 specs
What could we have missed and has this happened to anyone else? As it must have
Thanks
John
