>>>The only other thing that I can think of is to check if the array or an element of it, is passed as a parameter to a function somewhere. The function could be changing the array or its size indirectly.<<
>
>But, things most frequently go sour upon returning from the new code. In that routine one array element is assigned to a variable before being passed as a parameter. I wouldn't think there would be any way that could modify the original array element's value. Usually the array elements aren't empty upon returning, they just contain incorrect data. In one instance every element in the array was replaced with the same value, the PK! More commonly, only the other 3 numeric fields have been replaced. This causes an error when the application attempts to store the data back to the table because the PK's value is too large for the other numeric fields. In fact, that error is often the only symptom that something has gone wrong. What could assign the value from Case(2) to all 14 or so elements in the Case() array? Or even to the other 3 numeric elements?

If it's all the elements, just referencing the array name by itself (aYourName = 12345) would set the entire array to 12345. I don't know of anything that could set just the numeric elements. Does your code have lots of variables? Maybe you're overflowing the name table (an internal to VFP structure) and that's been known to cause strange problems. What version and SP of VFP are you experiencing this with? I know you said VFP9, but do you have SP1 installed (and the updated runtimes for the end users)?