July 11, 2008 at 11:30 am
What's the best method to access data for reports--DataSets or Stored Proceduers? Also, I see a lot of dynamic sql inside SSRS stored procedures which just seems wrong (given that imbedded dqsl inside sprocs will never appear in the excution plan). Is it really that difficult to pass filter values to sprocs??
any thoughts would be helpfull
thanks
al
July 13, 2008 at 11:41 am
In two different organisations I have used SQL inside the Dataset, and Stored Procedures.
Both work equally well.
Both accept parameters.
In my opinion Stored Procedures are the way to go simply because this gives you a little more control over source code, but that's just a personal view point, to be honest you can probably use either one equally well.
Good luck,
Nigel West
UK
July 14, 2008 at 7:42 am
Just my 2 cents...
I would recommend ALWAYS using a stored procedure in a report. I even have a naming convention for stored procedures that do nothing but return data for reports. The reason I say this is two fold; first, certain features (such as multi-select lists) require a stored procedure (unless I am mistaken), such as sending the delimited string of selected values. Second, it centralizes where to go to identify what tables and views etc are used. We use SSRS and Business Objects (Crystal Reports), and we are currently in the process of migrating our primary back-end reporting databases (as we improve them) from one server to another. It is nearly impossible to identify all connections to the various tables and databases, making it very difficult to cut out and move a single database at a time.
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply