>Personally, I'd rather dimension and initialize the array to keep the program from crashing should the query return empty for any reason.

Tommy;

It is always best when designing a system, to consider that all tables will be blank at some time. This is a good practice regardless of how you are creating your data. I keep databases with tables in various states - no data, valid data and invalid data (known problems - like parent no child, child no parent, etc.). Testing with all three types of data is more likely to contribute to the success of an application.

Another example is in "navigation code", to test for EOF or BOF (pre client/server). You also have to test for the possibility of both conditions existing at the same time. Why should the user get an error message when a table is empty? By the same token, you should not allow navigation buttons to be enabled without any records in a table. There is "no where to go". You cannot "Edit" a record, but you can "Add".

I think this is a good concept to follow for any application. Always presume the worst and you will not be suprised! By making this a programming "habbit", you will not have to think twice about such matters.

With Visual FoxPro, you can build these concepts into your foundation library and life is so much better!

The same concepts can be used with Visual Basic - it just takes a few thousand additional lines of code for a business application. In VFP, do it once and reuse the object/method as required.

Tom