>All,
>
>I'm seeing issues with COPY TO ARRAY. The following illustrates it on my machine today:
>
>

create cursor ffff (g_ggx c(1))
>insert into ffff values ("A")
>insert into ffff values ("B")
>insert into ffff values ("C")
>insert into ffff values ("D")
>insert into ffff values ("E")
>declare laTest(50,1)
>laTest=""
>COPY TO  laTest FIELDS g_ggx
>SET STEP ON

>
>Looking at laTest content in Debug, first 5 rows ought to be populated with field content- but nix. HELP refers to Tables as source for COPY TO ARRAY and there's no mention of Cursors, but SCATTER to ARRAY from a cursor works beautifully and I'd expected COPY TO would too.
>
>Issue is that I want that array size to be maintained with blank rows for the surplus. The other option is SELECT into ARRAY, but Tamar's paper calls that an order of magnitude slower for a small resultset and it also truncates the array- which breaks the intended model.
>
>Any advice appreciated! I've experimented with NOOPTIMIZE and FOR .T. as well as large cursors that ought to spool to disk (in case it's the memory-residency that's the cause) but it reproducibly refuses to populate the array from a cursor....

As Rod Paddock pointed out, you forgot to type as "Copy to array".

I jumped in to make a note about the alternative SELECT ... INTO ARRAY. It is similar but not the same and IMHO is preferable. I don't agree it is slower.

It doesn't "truncate" the array but makes the array length match how many rows you have in the result set and IMHO that is a PRO. Copy To Array OTOH, might return you more or less than what should be. ie: If your array is (2,1) and result set has 1000 rows and 10 columns, you still end up with 2 rows and 1 columns. That can be used on purpose if you know what you are doing, otherwise it is a CON. IOW, with copy to array you need to know rows, columns count in the result set. With COPY TO ARRAY you also have a scoping chance (FOR, WHILE, NEXT ...) which defaults to ALL.