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