Hi Kevin. Thanks for your reply.

My 2 joins was just an example. In VFP, I quite frwquently would have more than 3 joins with lots of where conditions, and from experience have found that breaking it up into a no. of joins is
1. Easier to follow
2. Easir to Debug
3. Usually more efficient
as you are crating Subsets all the way, and then working from these subsets on the subsequent selects.
I also dont want to limit apps to Sql server as most of our clients are currenlty using VFP, and would like the option, with whatever the solution is, to ensure that it works in VFP and SQL.

Taking your comments on board, is it not possible to have multiple selects as a source into a SqlDatasource ?

Regards,

Gerard



>Select * from Customers Join Stocks on X=Y where Cus_Area = "USA" into Cur1
>Select * from Cur1 Join Sales on A= B where Sal_Val > 1000 into Cur2
>Select * from Cur2 Join Groups on F=G where Grp_type = "ABC"
>
>Gerard,
>
>I'm not sure I understand why you think that one query is too complex...you're talking about two joins and three criteria conditions.
>
>If you're using SQL 2005, you could investigate common table expressions, which are sort of like temporary views/temporary derived tables. CTEs allow you to construct a query to do some of your filtering, and then perform subsequent filtering of the first result set. They can help "break out" complex queries into one or more parts: but IMO, what you've described is better off in one query (unless that was a subset of it, and there's more to it than just three tables).
>
>Kevin