>>>>>>>>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?
>>>>>
>>>>>A statement like | case=m.case(2) | would do the first.
>>>>
>>>>Hi Jim
>>>>
>>>>An array is in a sense a collection of variables, not a variable itself. It gets confusing to see m.case = m.case(2), because this will assign a single array element to the entire array. Just a suggestion: don't put mdot on arrays because they're a different animal. By not putting mdot on them, they stick out further from the surrounding code.
>>>
>>>Just another suggestion... try it without the m-dot.
>>
>>I'm not sure what you're suggesting.
>>
>>From the command window
>>
>>dimension laTest[2]
>>laTest[1]="hi"
>>laTest[2]="jim"
>>laTest = "hi jim"
>>display memo
>>
>>laTest Pub A
>> (1) C "hi jim"
>> (2) C "hi jim"
>>
>>If I had written
>>
>>m.laTest = "hi jim"
>>
>>I would have gotten the same effect, but it's terribly confusing because laTest is not a single memory variable.
>
>Typing CASE(2) = 112 gives an error, so I assumed that the CASE(2) without the m. would have raised an error, but I see now that it doesn't.
>
>I don't see how a "m." in front of any array variable name would be "terribly confusing". I don't know of a rule that says that "m." is to be used for only 'single' memory variables.
>And if one did get confused at seeing " m.laTest " I'd have to guess they were in the wrong business.
>
>cheers

VFP9 SP1

select * from table into array m.latest && error select statement is invalid

select * from table into array latest && works

An array is not a memvar. By the way, others documented that SELECT into array produced an error as far back as FPW.

http://fox.wikis.com/wc.dll?Wiki~EssentialMDot