Based solely on what you've posted in this thread I'd be hesitant to say there's nothing to worry about.
You've posted in other threads about using a stored proc to populate a table, and then running follow-on queries against said table.
If these follow-on queries are outside of the stored proc then you have a major issue, eg:
- session #1: calls myproc => truncate/populate mytab
- session #2: calls myproc => truncate/populate mytab
- session #1: select from mytab => pulls data generated by session #2
If this is your scenario then I can think of a couple workarounds:
1 - have the session create a #temp table and then have the stored proc populate the #temp table, eg:
- create #mytab(...)
- exec myproc => populates #mytab
- select ... from #mytab
2 - make sure each session identifies its rows in the table, then modify proc to only work on a session's rows, eg:
- add spid/int column to mytab
- exec myproc => delete mytab where spid = @@spid, insert/select @@spid,...<rest_of_data>...
- select ... from mytab where spid = @@spid
---------------
If this doesn't address your concerns then you need to post a complete example of what you're trying to, ie, when is the data created, when/how is the data referenced, how long will the data need to reside in the table, etc.