No, I think that you are correct. When you design a report, you set a template of what fields are expected in the report (or more importantly what fields will be displayed/used). You can send more fields than existed at the time of the reports creation, but you must always send the fields that are displayed/used by the report...otherwise you get an error.
Depending on the number of components an how you call Crystal, you might be able to create a series of reports, but that becomes a maintance headache, what would be easier to do would be to modify the XML so that every component is defined in the table structure...XSD (actually you just need and XSD file with all of the component fields defined, since the XML file usually bother to pass empty fields). Now any component not passed appears as a null value. You can choose to suppress the fields that are null so that they don't display on the report.
Now would be the really hard part, how to make a decent looking report with random fields being blank. What I have done, and it gets redundantly boring and semi complex is to pass a field in a second table that determines the order of the columns on the report...depending on the subtotalling needed there can be a lot of formulas running to create totals that are needed. Another method would be to put each component on its own detail line and then suppress the lines where the fields are null.
All of my reports run off of XML files, so I have a bit experience, but I usually ensure that all the fields desired are in every dataset. If nothing else, this might be the start of an idea that solves the problem.
Hope some of this helped...
IP Logged
