wendy elizabeth (6/25/2014)
The questions are:1. Can I use a temp table called '##temp' in the firstdata set and have the other 4 datasets refere to '##temp'? I am asking the question since all 5 datasets use the same stored procedure. If this possible, can you tell me how to setup the code?
In theory, yes, but reality, no. You have to make sure they run serially and not simultaneously, which I'm not sure you can do from SSRS as unique Data sets. I don't know of way without sub-reports to make a dataset dependent on the completion of a different dataset.
Add to the problem you'd have to make sure that two users wouldn't step on each other with different filters because the ##temp is completely global, not connection global, and could also disappear (which would be good) causing errors on the second user.
End result: Don't do this. It's painful at best, fraught with errors on average.
2. When I am running visual studio 2008 and create a temp table called '#test'. I get results. However if I change the sql for the dataset and rerun the query, the results from the orginal temp table remains. The column headers remain the same, but the data that is returned is from the original query before the dataset was changed. I found out that I have to stop by visual studio 2008 session, and start a new session for the new values for the dataset to be returned. In the original dataset code I had the statement drop #test and that did not work. Thus can you tell me how to solve this issue?
You're generating #Test via in-line SQL, I assume rather than a proc? When you say you change the sql and rerun the query, I assume you mean you're changing the inline SQL in the Dataset with a completely different query (but similar result sets), or are you changing a comment?
However, in short, VS is... quirky. It caches a LOT of things. SSIS packages have a similar problem with configuration loads. My guess is that it runs the query then is cacheing the results for reruns and it's not detecting the change (or it considers the change to not require a rerun). If the parameters or something changed that should also force it to rerun the process.
That it won't DROP TABLE #Test is something I've not come across before, would take me some research. I do all of my dataset control via procedure and just pass parameters down. Makes my life easier in most cases, so I'm not familiar with this issue... yet.
Never stop learning, even if it hurts. Ego bruises are practically mandatory as you learn unless you've never risked enough to make a mistake.
For better assistance in answering your questions[/url] | Forum Netiquette
For index/tuning help, follow these directions.[/url] |Tally Tables[/url]
Twitter: @AnyWayDBA