You can do a Query based on a Query in SQL, but not [easily] based on a Stored Procedure.Its not really like Access though ... I remember (a long time ago!!) when we had a complex query to do in Access we would:Do the inner part of the query, save it as a query.DO the next level query, using the previous saved query for part of it.I probably tried to do "something similar" when I moved to SQL, but I don't any long as I suppose I have learnt the "SQL way One route that might help you, as you transition, would be to CREATE and then use a VIEW. You might find that similar to Access in a way that helps you.CREATE VIEW MyViewAS SELECT Col1, Col2, Col3 FROM MyTable WHERE ColX = 'FOO'GO
thenSELECT Col2FROM MyViewWHERE Col3='BAR'ORDER BY Col1
If you want/need to use a temporary table with SProcs you would be better off with a #TEMP temporary table rather than an @TEMP Table Variable. @TEMP tables have very limited scope and capabilities (compared to full blow database tables) and you can't do things like inserting the results of an Sproc into them.If you create a table in your outer level code e.g.CREATE #MyTable( Col1 varchar(10) NOT NULL, Col2 int, PRIMARY KEY ( Col1 ))
you can then EXEC a Stored Procedure which, itself, can do:INSERT INTO #MyTable( Col1, Col2, ...)SELECT Abc1, Abc2, ...FROM MyTableWHERE ......RETURN
Because the #TEMP table is created in the outer code it is "in scope" in the inner code. Once the outer code returns (to its caller) the #TEMP table will be automatically dropped.