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

All excellent advice!

>The same concepts can be used with Visual Basic - it just takes a few thousand additional lines of code for a business application.

FOFLMAO... (now that was mean!!)

>In VFP, do it once and reuse the object/method as required.

Sounds good to me!

Thanks....

Tommy