Well, after much internet searching and re-reading my text on multi-dimensional array syntax for the 100th time, I discovered an example of the ReDim Preserve statement in a static array in which ArrayName(3, 8) could be resized (via ReDim) to ArrayName(3, 15) but not to ArrayName(5, 8) because only the last dimension (2nd or last subscript) can be resized. I know it pained the author mightily to divulge this important piece of information. Even then he skillfully hid it in the explanation of a static array, which is rarely re-sized, and only then did he let the secret out in an example rather than an explicit statement like: WHEN EMPLOYING DYNAMIC MULTI-DIMENSIONAL ARRAYS, IT IS IMPORTANT FOR ALL YOU PROGRAMMING FOOLS AND RESIDENTS OF PALM BEACH COUNTY, FLORIDA TO UNDERSTAND THAT ONLY THE LAST SUBSCRIPT CAN BE REDIMENSIONED USING THE ReDim Preserve STATEMENT TO SAVE THE DATA ALREADY IN THE ARRAY. That makes it too easy and removes all of the sport of appearing to teach when the author's real object is to play, "button, button, who has the button?"Further obfuscating the issue is the apparent national secret that Excel VBA uses the syntax ArrayName(row, col) while Excel itself uses (col, row) to identify a cell location -- as in A12. This is designed to trap unsuspecting developers who foolishly expect that a product's designer would be consistent in the syntax of two features of the same product! WRONG!Therefore to comply with all of the peregrinations of the Excel VBA syntax, a 2-column array of indefinite rows can only be resized by writing it ArrayName(col, row) -- in apparent violation of the syntactical convention. In fact, VBA's syntax sees this as a 2-row array of indefinite columns. Thus, anyone who has retained his sanity to this point and wishes to fill a two column, resizable array, must dimension it as ArrayName(2, variable) and would call the elements of the array on "row" N as ArrayName(1, N) and ArrayName(2, N).HOWEVER, (are you ready for this?) when one wishes to manipulate the array data elements, as in a sort routine, using a VBA function (e.g. LBound or UBound) or a VBA procedure (e.g. For ... Next) regardless of the way the array was declared and filled, VBA functions and procedures require the syntactical row and column convention to be followed. This compels one to sort a dynamic, resizable array in the following curious way,For Outside_Increment = LBound(ArrayName, 1) To (UBound(ArrayName, 2) - 1) For Inside_Increment = (Outside_Increment + 1) To UBound(ArrayName, 2) If ArrayName(1, Outside_Increment) > ArrayName(1, Inside_Increment) Then Temp_Hold_Data1 = ArrayName(1, Outside_Increment) Temp_Hold_Data2 = ArrayName(2, Outside_Increment) ArrayName(1, Outside_Increment) = ArrayName(1, Inside_Increment) ArrayName(2, Outside_Increment) = ArrayName(2, Inside_Increment) ArrayName(1, Inside_Increment) = Temp_Hold_Data1 ArrayName(2, Inside_Increment) = Temp_Hold_Data2 End If Next Inside_IncrementNext Outside_Incrementleading to a satanic stew of procedures and functions that follow the row/column convention, while the array variable and data calls follow the array declaration syntax -- all of which I learned by trial and error over five frustrating days. If one were to logically write in the procedure above the statement,For Outside_Increment = LBound(1, ArrayName) To (UBound(2, ArrayName) - 1)which complies with the array format, instead of the syntactically correctFor Outside_Increment = LBound(ArrayName, 1) To (UBound(ArrayName, 2) - 1)he will be promptly abused with a "compile error" pop-up that says (can you guess?) "missing parenthesis." This message is designed to throw the unsuspecting fool of a developer off track and perhaps stretch his quest for a rationale to possibly months or years -- assuming, of course, his sanity lasts that long.

Thanks for clearing it up BigBill - don't you feel like you were abducted by aliens ?

I sure do. I think they're home base is somewhere in the northeastern US