Yes, I have created hundreds of reports of all different kinds, from all different datasources, including very standard items like invoices and quotes and very complex reports such as analytical chemistry certificates of analysis. I've worked with reporting tools like crystal and ssrs for about 6 years and I'm pretty good with T-SQL, PL/SQL and MDX, but of course there is always more to learn.

When you created the @QuoteID parameter, how did you use it? Normally you would edit the SQL so that it filters the data prior to it being returned to the report.

e.g.

select field1, field2...

from table (join table 2 etc)

where QuoteID = @QuoteID

This is tried and true and it works well. You don't really want to be bringing back 10,000 records to a report and relying on the report to do the filtering (e.g. using it as a tablix filter or row filter) because it will be extremely slow.

That same technique will work if you just use one query, or five. If you do five queries you will need to add that same @QuoteID filter to each query.

When you say "wrong outputs" what exactly do you mean?

If it is just duplicates, then that's going to be due to the nature of datasets.

If you join a header table to a details table, every header field will be repeated on every details row. That's a one to many relationship as you alluded to. That's what happens when you flatten data into a single dataset.

SSRS provides "groups" to deal with this. Grouping the rows, rather than just using the details within a table (which will show every single row in the dataset) you can only show the group rows.

I suggest you look at the results in the query you are using because it will be clear which rows are being duplicated and give you clues as to how to do the grouping.

It might be easier for you to use 5 separate queries because you can restrict each query to single rows for each raw material. The downside to 5 queries is that you will hit the database 5 times.

It sounds as though you have a good grounding in SSRS but are struggling with taking the next step to developing more complex reports. This particular requirement doesn't sound that complicated but I suggest you might need to do some advanced training or read up on SSRS techniques. 90% of the challenge in SSRS is writing good queries and if you come from a procedural coding background this can be very counter-intuitive. The better you are at coding in .NET for example, the harder it is to switch mindsets to start thinking about sets.

Don't be discouraged.

From here, if you want to provide more information then some screenshots, SQL examples, and dataset results will really help to explain what it is you are struggling with.