Er, I'm not sure I understand your question.  I'm assuming that the data returned takes up 70 pages on the report.  Yes?  Now, when you say "command object," are you talking about a .Net object?  Or are you talking about using a SQL Command to generate your dataset?

What sort of error are you getting?  Are you only seeing half the expected data on the report?  Or, is the application crashing, possibly due to a memory exception?

I would strongly recommend against trying to split the report into two cross-tabs, and then trying to marry them up.  Even if you could get it to work, it's going to be much more of a headache than it's worth.  It would be much better to focus on why the one cross-tab is only using half the data.

You have a SQL query that takes up 70 pages?!?!? I'm not surprised that CR crashes on this. This should be in a stored procedure in the database. Wow. That must be a nightmare to maintain. I guess you don't have access to the database to save it as a SP?

*cough*  Please turn your caps lock off.  Using all caps is poor netiquette.


So, you honestly have a SQL query (i.e., SELECT ... FROM ... WHERE ...) that is 40 pages long?  Way before I got into trying to get fancy with splitting the cross-tab, I would take one big step back and revisit the query itself.  Because that is going to be a nightmare no matter how you slice it. 

What exactly is causing it to be so long?  Multiple complex CASE statements?  Convoluted joins?  A massive array of options for an IN comparison?  Multiple subqueries?  I mean, I've written some pretty complex queries in my day.  I don't think I've ever written one that would go past two pages.  Well, maybe three, come to think of it.  But 40 is right out.

Is there any way you could off-load some of that work back into the report itself?  Split some of the data up into subreports, and use shared variables to calculate aggregate data?  Use formulas to format some of the results? Allowing more data through, and just suppressing unwanted records? Normally, I'd advise against doing that.  But, this may be one of those exceptions that proves the rule.

If that kind of length is still necessary, and you don't have a way to push the work off into the database itself (try taking your DBA to dinner, you'd be amazed what a $30 steak can accomplish   ), then I'm not sure what to do.  I'm also still a bit lost as to how splitting the cross-tab will help with your problem.  Unless you mean trying to make it look like you are running a single cross-tab across multiple subreports.  In which case, my friend, I suggest psychiatric advice.  That is crazy talk.  There must be a better solution.