Lost link to TopN when converting graph field

[MycroftMkIV]

Instead of re-writing 250+ reports when we change databases, our software uses the Crystal Reports API to change the report in memory for the given database. The new database we are using is a challenge, as it has been completely re-factored with new tables and field names.

This means we have to scan a particular Crystal Report in memory and change or destroy/recreate all the report's objects. We have done this for everything in the report and it works fine, except for a problem in one particular area.

One of our reports uses a condition field in the graph object as an 'On Change of' data item, with a connected TopN value. When we create a new field object with a new field name to replace the old field object, we lose that connected TopN value. We know this since the TopN value is no longer a requested parameter.

Here are the steps we perform

For each Condition Field in the graph object
Store the Condition Field in an array of IFieldDefinition
Store the Condition Field Sort Order in an array of CRSortDirection
Delete the Condition Field from the graph object
end
For each Condition Field in the array
If the Condition Field needs to be changed
Add the changed Condition Field object to the graph object
Set the sort order
else
Add the old Condition Field object to the graph object
Set the sort order
end
end

The Delete line is where we lose the TopN connection. If the old condition field object is added back to the graph object, the TopN no longer exists.

We can't figure out how to get information about TopN for the field before deleting, so we can add it back. Does anyone know anything about this?

Mike

 

[lbass]

I can't be helpful with this kind of coding, but just a comment--the topN is not inherent to the field, but is a group sort, based on the value of the summary for that field as if it were grouped, so I would think you would have to somehow check the summary value in order to retain the topN ordering.

-LB

 

[MycroftMkIV]

Thanks for the hints. I have managed to work around this problem by changing the report so there are formulas in the condition fields instead of db fields. The formulas simply consist of the db field name. I then do not delete any condition fields that are not db fields, since formula names never need to be changed.

I appreciate the fact that practically no one gets into the Crystal API at the level that we have. We are now supporting three different DBMS (PostgreSQL, SQL Server and an unnamed third DBMS) with a single report by doing this kind of stuff, but it gets kind of nasty sometimes. There are absolutely NO books or references that teach this stuff. The Crystal tech reference is just a regurgitation of the information in the _TLB file I am using, so it doesn't help much.

Thanks again. Problem solved.

Mike