>Jay
>Thanks for your suggestion. The problem was solved when I changed the array
>from $ to & and made it smaller. Seems to run OK but it is still a 2D
>Dynamic.
>Barrie
>
You're right again--and I re-learned something.  DYNAMIC follows the same 
rules as XREF, where only the FIRST dimension is indeterminate. That 
means if you declare
DYNAMIC myArray$(1000,100000)
no memory is allocated, but if you then call
var$ = myArray$(x,y)
it will allocate (SIZEOF(STR255) * (x + 1 + gFBDynamicGrowInc&) * 100000) 
bytes. 

gFBDynamicGrowInc& defaults to 10, so if x = 1, that comes to (256 * 12 * 
100000) or 307,200,000 bytes. No wonder it choked!

You can, however, do this with with some expectation of success:
DYNAMIC myArray$(1000000,100)

Now the allocation (for x = 1) is just (256 * 12 * 100) or 3,072,000 
bytes.

Changing the array to LONGs instead of strings, as you discovered, 
reduces that to 4,800.

The rule of thumb is to dimension multi-dimensional arrays, whether XREF 
or DYNAMIC, with the smallest numbers you can manage AFTER the first. For 
3 or more dimensions, try to arrange them from largest to smallest:
DYNAMIC myArray(_maxLong, 50, 7)

The solution I proposed before makes both dimensions dynamic, allowing 
each x to allocate only the bytes needed for its own y's, making for far 
more efficient memory usage in many cases.

 e-e
 =J= a  y
  "