Specify field mapping when changing table location

[Former Member]

I want to change the tables in a report to refer to database tables with a different schema, and specify the mapping of fields in code.

I already have code that changes table locations successfully when the schema does not differ, using the RAS API. As far as I can tell, the RAS API doesn't have a way of handling schema differences. Is that true?

OTOH, the higher-level CR API does appear to have a mechanism to do field mapping, using the FieldMapping event in the ReportDocument class. I've been trying to use this API for the job, but I don't seem to be able to change the location of a table in the report.

Here's an example scenario:

• The report was created using an ODBC data source Source1 that contains a table Table1
• I have an ODBC data source Source2 that contains Table1 as well as a table Table2 that is identical to Table1 except that the field names are all slightly different
• I want to change the report so that it uses Table2 in Source2

I've managed to get the report switched to Source2 with code like this:

report.DataSourceConnections[0].SetConnection("Source2", "", id, pwd);

Here's the code I'm using to try to change the report table to refer to Table2:

            Table table = report.Database.Tables[0]; // only one table in the report

            TableLogOnInfo logOnInfo = table.LogOnInfo;

            logOnInfo.TableName = "Table2";

            table.ApplyLogOnInfo(logOnInfo);

            report.VerifyDatabase();

I've also tried the simpler

table.Location = "Table2";

Neither approach changes the table location. I know this because when I preview the report I see data. Since the field names are all different, changing the location should have removed all the fields from the report. (Also, the event handler I have hooked up to the FieldMapping event is not called. Yes, I did enable the event in the ReportDocument.)

So:

1. How do you change the location of a table using the high-level API?
2. If you change the location using the RAS API, is the FieldMapping event fired? (Haven't tried this, but somehow I doubt it.)
3. Is there a way to do field mapping with the RAS API?

Thanks!

- rick cameron

[Former Member · Accepted solution]

I've found the answer to #1: it helps if you spell the name of the target database table properly!

So setting table.Location = newTableName works. I know this because when I preview the report I get an unknown field error.

But the FieldMapping event is still not fired when I verify the database.

Cheers

- rick

[Former Member · Accepted solution]

I just found this thread from last September:

In it Ludek refers to SAP Note 1601018 which says that the FieldMapping event is only fired if you call ReportDocument.SetSQLCommandTable, not if you set database/table location by other means.

Is that still true with the current version of CR .NET? If so, I call that a bug. We cannot use SetSQLCommandTable to do the change of database location we want to do.

Cheers

- rick

[former_member183750 · Accepted solution]

Hi Rick

This is not considered a bug. It is a limitation that has been discusses extensively in many of our internal meetings. The implementation job proved to be much too massive and with highly limited ROI. E.g.; the number of requests for the feature is just not there...

- Ludek

Senior Support Engineer AGS Product Support, Global Support Center Canada

Follow us on Twitter

[Former Member · Accepted solution]

Hi, Ludek

Thanks for clarifying that. Would it be possible to update the documentation to make clear the circumstances under which the FieldMapping event is fired?

We would certainly find it useful to have this supported when setting location from one ODBC DSN to another. However, it sounds like I shouldn't hold my breath waiting for the necessary changes

Anyway, if this comes up again during your meetings about priorities, please mention us.

Thanks

- rick cameron

[former_member183750 · Accepted solution]

Yeah - that is a good suggestion. I'll ping the Program Manager about it.

Many thanks,

- Ludek