>If you do this the tables are refereed to as Table, Table1, Table2, etc.<

That's almost right ... I don't know if it's the same in VB as in C#, but since C# is case-sensitive it *does* matter that the first one returned is table, not Table. You're right about the others though, with capital T's ...

~~Bonnie


>The DataAdapters allow you to have more than one select statement in the SelectCommand. You can also write a stored procedure that returns multiple tables. If you do this the tables are refereed to as Table, Table1, Table2, etc.
>
>>>>The initial query is fairly complex (there are a dozen different conditions), so the query string still needs to be built in the middle tier and then passed to the stored proc.<
>>
>>It sounds like you are still running a SP. Are you passing some kind of string to it as a parameter?
>>
>>Anyway, as long as you are running a SP, you can return multiple result sets easy enough. Obviously, the benefit to this is not having two roundtrips back to the server, if the SP can return both result sets at the same time (the SP simply has two SELECTS ... if you can run the SP in the Query Analyzer, you'll see what I mean about returning two result sets).
>>
>>But, if the logic is really, really complicated, sometimes it's a major PITA to write it in T-SQL ... it just isn't flexible enough. So, doing some of the work in your code instead is a perfectly acceptable way of doing things, since typically your middle-tier stuff runs server-side anyway.
>>
>>If you're just running a Query and not a SP, I think you can still bring back multiple result sets by specifying two SELECT queries in your string (haven't done it, so can't say for sure ... but I *think* that'll work).
>>
>>
>>~~Bonnie