>>I've done some assembly back in FPD2.6, and I did it recursively, with cursors (for both updates, recalcs, and multilevel display). So I don't see what would be the problem that forced you into arrays?
>
>Each time through the recurssion I select a set of records for the subassembly from my BOM table and process them. Any one of the records in that resulting cursor could be a subassembly requiring a recursive call back to the same procedure. Then, when the procedure goes to select the records for the lower level subassembly, the select clause would would write over the cursor from the higher level subassembly that called it.

Not necessarily. Here's how I solved this: I had a recursion level counter, and based the cursor name on it. So each level of recursion had its own cursor, and had to close it for itself. In cases when I needed the results of all levels in one place, there was one master cursor with the results, and each recursion level would insert records into it.

>There were certainly work arounds I could have used to name cursors based on the subassembly and/or the level I was in the BOM to prevent writing over cursors. I did consider that as an option when writing the routine; But I concluded the array solution would protect my recursive datasets easily by scoping locally and would result in less messy code. I have no regrets. My code would have been breaking anyway if I wasn't sending the proper parameters to my output function.

Ah, so it was a design decision. I was thinking you had problems and the arrays were a workaround. Still, good to know there's always at least three ways to do something in Fox :).