In the case where you cannot post, you just need to be as precise as possible with your description and hope people understand.
MM I would agree with this and, from 20 years of answering people's reporting questions, 8 or so of them RDL-specific, I would like to add the two following points:
1. A lot of the problems that people ask about RDLs are solved *in the act* of recreating the problem with generic data and a simplified design. Either the problem disappears and they can figure it out by adding in one layer of complexity at a time, or they just see their own problem more clearly when they do this. So it is always a good idea to insist on it; I used to have a list of requirements pointing this out on my blog somewhere.
This point isn't really limited to RDLs and I'm sure people have made it all over technical forums. But there is something about RDL design and also DTSX design -- the layers of design using different technologies and the different places you can implement any particular type of functionality -- that seems to especially require this reminder:
* You must provide simplified steps to repro
* when you do it, you aren't just making it easy for somebody else to resolve your problem. You are making it easy for *you* to find, articulate, and even resolve, your own problem.
2. it is extremely easy to provide generic data in an RDL without going to the effort of creating an embedded XML data set, as follows:
*- change the data source to look at localhost rather than your server info, and request that the recipient make the very simple required change to this source info, if this most-like-case doesn't work in his/her development environment for some reason
*- if the SELECT statement was previously embedded in the RDL:
*-- change the expressions in the existing columns list to be quoted or constants - I like to quote the existing expressions rather than just putting in any constant is that this retains a flavor of what was intended in the original.
*-- change the source table information to look at master.dbo.spt_values or something equally innocuous
*- if the SQL pointed at a view or a stored procedure, or if you don't like the idea of quoted expressions as your actual data result, just switch out the SQL for a couple of UNION'd SELECT statements. I don't even think you have to put in a FROM clause.
>L<