On 2/23/2016 5:01 PM, Hoteltravelfundotcom wrote:
I don't want to add a entry field if possible. This is in IBS and then
would require updating their XT Java screens. As this is a fix, I wanted to
minimize my involvement. The one field gets order# for 2 other files that
get user locks and it clears it. But ours is an alpha field on the key.
If I understand it, someone at your company has created a 'sister' table
which is supposed to track along with IBS tables, but which has a
different key structure. That's unfortunate.
Here's one reason it's problematic to stick with a numeric input field.
Let's say that at any one time there are dozens of orders which are
supposed to be 'locked' due to the natural course of processing them.
Here are two of them:
' 012345'
'0012345'
It so happens that for some reason, a program crashed while working on
'0012345' and now the user wants to use the fixit program to unlock it.
The user types in 0012345, hits Right Adjust, the program reads the
value as 12345 because it's a number after all.
The new code converts it to character and it becomes '12345'.
Chain with '12345', not found.
Add a leading zero and try again.
Chain with '012345' - found it.
Unlock '012345' - the wrong order. '0012345' remains locked.
At this point, the user will put in a help desk ticket asking for order
number '0012345' to be unlocked because the unlock fixit program does
not work. She won't tell you that the wrong order was unlocked, and who
knows what that means for the rest of the processing that '012345' needs
to go through.
This is at least one scenario where the proposed fix will not work.
Every solution seems to spawn a new problem, and the new solution is to
iterate through every leading zero possibility, so
' 012345'
' 0012345'
' 00012345'
' 000012345'
' 0000012345'
' 00000012345'
'000000012345'
Which seems satisfactory so long as you don't care that you've unlocked
7 orders instead of one.
What happens if an order gets unlocked when it's supposed to remain locked?
midrange.com
