>Mike,
>>
>>select * from table into array m.latest && error select statement is invalid
>>
>
>this is a VFP bug.
>
>>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.
>
>An array is a memvar, of course, and it consume a MVCOUNT element.

Yes, an array takes up one mvcount no matter the size. I understand that.

I chose to treat an array as a different beast from a regular memvar. Thus I have a common way to deal with arrays and a common way to deal with memvars.

I only have to remember one exception for m. on memvars, not to use them with macros. I have zero exceptions to remember for arrays.

>
>Another example; you can transform a scalar memvar into a array memvar:
>

>CLEAR
>local memvar
>memvar="local"
>LIST MEMORY LIKE "m*"
>DIMENSION m.memvar[1]
>LIST MEMORY LIKE "m*"
>RELEASE memvar
>

>
>>

What does that prove? The original m.memvar was destroyed (as evidenced by the fact that the original content was lost) and a new array was created.

Show me how my suggestion is inconsistent in some way and I may reconsider. By avoiding m. on arrays I've had no bizarre side effects and have not seen the error CFK reported on the wiki.

One cannot name a field the same as an array element, so there's no possiblity of conflict.

It is faster to use it for each element, so that's something.

LOCAL ARRAY LATEST[5]
A=SECONDS()
FOR X = 1 TO 1000000
  LATEST[1]=1
  LATEST[2]=2
ENDFOR
?SECONDS()-M.A

A=SECONDS()
FOR X = 1 TO 1000000
  M.LATEST[1]=1
  M.LATEST[2]=2
ENDFOR
?SECONDS()-M.A