• The hard part is creating the temp table before it is populated because the stored proc output is dynamic. The only solution I can come up with is to basically call a stored procedure that does all the dynamic stuff and returns the table structure of what the "original stored proc" will return. Use that table structure to build the temp table and then call the "original stored proc" to populate THAT temp table and then do the joining with other physical tables from there.

    Aside from the performance hit I will have to take from calling the additional stored procedure, do you see any holes in this theory? Do you have any other ideas on how to populate a temp table without a predefinition of table structure? The end result is that I have to join the stored procedure results with a couple other tables, then spit the results from the final sql join into a web gridview and then the user can perform manual searching and filtering from there....this is for manual user data analysis.

    I hope the above paints a decent picture and I didnt just cause confustion. Let me know if thats the case 🙂

    Thank you!