Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase «««123

working with multiple dataset withing a table in SSRS Expand / Collapse
Author
Message
Posted Saturday, October 16, 2010 2:35 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Yesterday @ 7:59 AM
Points: 195, Visits: 761
I concur with SSC-Enthusiastic.

You'll only need to cross data sets if the two things you want to mesh are from different servers. Otherwise you can combine the two tables (even across databases) in a single T-SQL statement, and then use simple groups on the table to display it how you want.

2008R2 lets you do limited lookups, and another poster mentioned code-behind, but I consider such trickery to be beyond most mere mortals and usually more trouble than they're worth :P

PS: I don't usually resort to violence but the world would be a better place with one less scab in particular from this thread leaving alive.
Post #1005677
Posted Sunday, October 17, 2010 7:37 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 3:21 PM
Points: 35,955, Visits: 30,249
Doug Lane (10/13/2010)
Jack isn't saying multiple datasets are bad; he's saying trying to blend multiple datasets in the same table control is bad. RS just wasn't designed to take more than one dataset per control. That said, whether we can all get along or not, gjyothi still would like help.

If I understand the problem correctly, you want to show something like this:

Invoice1
___MeterInfo1 ... ... ... ...
___MeterInfo2 ... ... ... ...
___MeterInfo3 ... ... ... ...
Invoice2
___MeterInfo1 ... ... ... ...
___...

If that's the case, I think Jack is right in that it's easier to merge two sets of data on the back end than it is to try to mash them together in RS. If someone has a more efficient hack for that, I'd love to hear it.

Edit:I just noticed there was a whole second page of posts after I responded, so, um, yeah...sorry about that.


This is an old post and I suspect the OP is long gone... however... a simple two level hierarchical result set would certainly do the job here. A hierarchyID column (or the equivalent) to sort on would do the job nicely.


--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1005963
Posted Sunday, October 31, 2010 1:24 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 26, 2012 4:29 AM
Points: 3, Visits: 43
I came across the following post which may be of use to the OP:
http://www.sqlservercentral.com/Forums/Topic429975-150-1.aspx?Update=1 also do you think that perhaps using a list as a "back bone" off which you can then group and hook the other datasets too using parameters?


www.host-junction.net
Post #1013614
Posted Sunday, October 31, 2010 2:15 PM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 12:20 PM
Points: 41,529, Visits: 34,445
Please note that this thread is 2 years old.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1013619
Posted Monday, November 01, 2010 6:49 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 3:21 PM
Points: 35,955, Visits: 30,249
Heh... makes no moxnix... some revived conversations are just as fun.

--Jeff Moden
"RBAR is pronounced "ree-bar" and is a "Modenism" for "Row-By-Agonizing-Row".

First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."

"Change is inevitable. Change for the better is not." -- 04 August 2013
(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1014227
Posted Tuesday, November 02, 2010 3:49 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, November 26, 2012 4:29 AM
Points: 3, Visits: 43
Yes I realise that, but very often the threads will be referred to over and over again as people learn from what others have done before them. I am sure that if it was irrelevant then people would have marked it for archive.

www.host-junction.net
Post #1014342
Posted Wednesday, June 29, 2011 4:58 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, October 11, 2013 6:01 PM
Points: 10, Visits: 66
Exactly. I've got the same issue 2 years on and here I am in this thread. I've got a pretty complicated annual statement report for about 2000 superannuation members, each one about 10 pages long and lots of detailed tables about different stuff for each member. Doing it all in on Stored Proc would be a nightmare.

So I have a main SP that gets all the basic info for each member (name address etc etc) then I need to call a load of other procs for each member. I think the subreport option is going to be the best bet. Not sure why I didn't think of that!

BTW it was worth it to see BSRLong in action. Good to see that the thread made it back on subject. Hopefully he is off spending less time on forums and more time on learning english and basic social skills...

Thanks for all your input,

Dave
Post #1134159
Posted Wednesday, October 09, 2013 5:58 PM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Tuesday, April 01, 2014 6:12 PM
Points: 827, Visits: 342
Hey BSRLong,

Where are you? And where is your solution?
Post #1503333
Posted Friday, October 11, 2013 6:08 PM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, October 11, 2013 6:01 PM
Points: 10, Visits: 66
Amit Raut (10/9/2013)
Hey BSRLong,

Where are you? And where is your solution?


hahahahaha God what a blast from the past this thread is. Can't believe that was over 2 years ago.

I somehow managed to struggle on with my solution without any further input from BSRLong, God only knows how...

Post #1504176
« Prev Topic | Next Topic »

Add to briefcase «««123

Permissions Expand / Collapse