>>>>>>>>>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

There are TWO of you now arguing in disfavour of "m." for arrays.
Both on the basis that the "m." causes failure when used in SELECT...INTO ARRAY.

*MY* opinion is that never using "m." with arrays because of one (or even a couple of) odd-ball limitations (probably bugs) is akin to using an A-bomb to kill a gnat.
I try to use "m." ***ONLY*** where it is needed. You promote using it everywhere, to which I have no objection EXCEPT that an array is a memory variable and you have a 'hidden' rule to not use it with arrays.

When an array is dimensioned it counts as only 1 in terms of the "MEMLIMIT". You can call it 'more than 1 variable' all you want, but VFP doesn't seem to follow your definition.