> >I suggested SELECT/INSERT as one possible alternative, not necessarily > >as the best or only alternative. Then I justified the suggestion. I > >was hoping not to have to defend the suggestion, but that's what you > >seem to want. I apologize, but I will not oblige this. > > Not at all. But I always avoided to use SELECT/INSERT with arrays and maybe > it's a mistake. This is why I asked. Sorry if it sounded in any other way. > English is not mother tongue. :) Sorry about this, Vlad. It's a beautiful day (25 degrees and sunny) and I am in working all day. I guess that has made me quite a bit grumpy. I've actually found SELECT and INSERT with arrays to be extrememly useful. The only caution would be to check that the SELECT returned some rows and, if not, issue a DECLARE {array} so that subsequent array operations won't blow up. It's actually kind of cool, because if the SELECT statement returns no rows, then there is no array. If you then declare the array, it is scoped to what the original array was, not necessarily to the current program. Here's what I mean: PRG1.PRG: declare laTopLevel(1) do PRG2 ? laTopLevel(1) PRG2.PRG SELECT * FROM {table} INTO ARRAY laTopLevel IF _TALLY = 0 * laTopLevel doesn't exist, so we create it. DECLARE laTopLevel(1) ENDIF LIST MEMORY At the end of PRG2, you will see that laTopLevel has been scoped back to PRG1. /Paul