Your welcome, and you are probably correct, there is nothing wrong (and often the better way) with using multiple SELECT's. The key is figuring out how to describe your result set.

>the normal/denormal table concept (which i'm assuming is another term for good design/bad design)

I don't want to start another Normalization thread (like I said the topic was thoroughly discussed here recently), but it simply refers to how data is represented in the tables. Its a method for addressing update and maintenance issues. If you look at t4 in the example, you will have the Sales rep's name in every record where they have an entry (and multiple times the company name will be in there for each date entry) If the Sales rep changes their name, it will need to be changed in all records in t4, or 1 record in t1.

In itsefl it doesn't answer the good/bad design question, sometimes performance, and other considerations make denormalization desirable. Being able to describe the data denormalized though is important IMHO for getting your SQL JOIN's down. It still bends my head sometimes, and I had to rethink that example before a bit to get it right.

A good book on SQL would probably do you good (I don't know any off hand, but VFP SQL is a subset of T-SQL the SQL Server dialect).

Best,
Bill