Hello, and thank you for writing with ideas about this.
It turns out this issue has been on the books with OneWorld Support since September 2001.
This JDELIST discussion from 7/11/2001 refers to SAR #5498266, which was fixed in all service packs since 18.1. Since we're on Service Pack 15.1, I'm way behind.
Here is an updated description of my problem:
>>>
Most of my P4210 users, at one time or another since migrating to Windows 2000 terminal servers, have experienced doubling of certain lines when processing sales orders or credits. The "doubled" line is corrupted--some blanks contain no data or invalid data. I suspect that something in the application is trying to update a line, but instead adds this partial line--resulting, if not caught, in extra product being shipped to our customers.
We have been using OneWorld Xe since November '02 and did not have any problems like this on our Windows NT terminal servers. We have not modified P4210 and have tried, at various times in the troubleshooting process, deleting user overrides for the users in question.
<<<
The final word from OneWorld Support: The problem exists in the system Tools and cannot be fixed by customers.
I learned all this today from OneWorld Support, who directed me to Document ID ODS-02-0029 (PeopleSoft Solution #200782275) from 10/25/2002:
>>>
This notification is to inform you of a recent issue discovered in slower performing terminal server environments, in EnterpriseOne and ERP 8, where the primary symptom displayed is a duplicate line written when editing an existing sales order.
All releases of PeopleSoft EnterpriseOne and ERP 8.0 can be effected by slower performing terminal server environments.
This communication serves the purpose of making you aware of the issue and the service pack downloads that will assist you in a resolution in slower performing terminal server environments.
The following service packs can be downloaded from the Update Center on the Knowledge Garden under: Support/Update Center. Target release dates for these updates can also be viewed from the Update Center. The fix should also be included in any subsequent Service Packs that are released.
.
.
.
Please note, subsequent to applying the fix, you may notice a slight difference in processing time. Please be aware that you will not be able to return to a row and perform updates until the "asynch" event on that row is complete.
<<<
The tech support person said there is an asynchronous process running behind the grid all the time, and on "slower" machines it can get confused; when it gets lost, it ends up creating a new line. She also referred vaguely to "custom grids" (user overrides, I assume) contributing to slowing down the process -- and also clerks who go too fast. The fix actually forces the process to be synchronous: Line 2 cannot be changed until Line 1 is successfully updated.
It's strange because we really did just upgrade our terminal server hardware, so I'm unsure why that would be the bottleneck. Our team has been discussing, however, how much work has been added to our AS400/iSeries database server in just three years -- so maybe that's the real problem. Though, that still doesn't explain why I have a handful of users who see this 75% of the time during their week, but no one else.
The whole thing is just freaking bizarre. At least everyone, so far, has agreed about THAT.
-Tim