Reports fail when run against a different data source

Question

Hello,
We have a VB.NET 2008 WinForms application running on Microsoft .NET 3.5. We are using Crystal Reports 2008 runtime, service pack 3 -- using the CrystalDecisions.Windows.Forms.CrystalReportViewer in the app to view reports. In the GAC on all our client computers, we have versions 12.0.1100.0 and 12.0.2000.0 of CrystalDecisions.CrystalReports.Engine, CrystalDecisions.Shared, and CrystalDecisions.Windows.Forms.
Please refer to another one of our posted forum issues, u201CCritical issue since upgrading from CR9 to CR2008u201D, as these issues seem to be related:
Critical issue since upgrading from CR9 to CR2008
We were concerned with report display slow down, and we seemed to have solved this by using the Oracle Server driver (instead of either Microsoft's or Oracle's OLEDB driver).  But now we must find a resolution to another piece of the puzzle, which is:  why does a report break if one data source is embedded in the .rpt file is different than the one you are trying to run the report against, in the .NET Viewer?
Problem:
If you have a production database name (e.g. "ProdDB") embedded in your .rpt file that you built your report from and try to run that report against a development database (e.g. "DevDB") (OR VICE VERSA -- it is the switch that is the important concept here), the report fails with a list of messages such as this:
    Failed to retrieve data from the database
    Details:  [Database vendor code: 6550 ]
This only seems to happen if the source of the report data (i.e. the underlying query) is an Oracle stored procedure or a Crystal Reports SQL Command -- the reports run fine against all data sources if the source is a table or a view).  In trying different things to troubleshoot this, including adding a ReportDocument.VerifyDatabase() call after setting the connection information, the Crystal Reports viewer will spit out other nonsensical errers regarding being unable to find certain fields (e.g. "The field name is not known), or not able to find the table (even though the source data should be coming from an Oracle stored procedure, not a table).
When the reports are run in the Crystal Reports Designer, they run fine no matter what database is being used; but the problem only happens while being run in the .NET viewer.  It's almost as if something internally isn't getting fully "set" to the new data source, or something -- we're really grasping at straws here.
For the sake of completeness of information, here is how we're setting the connection information
        '-- Set database connection info for the main report
        For Each oConnectionInfo In oCrystalReport.DataSourceConnections
            oConnectionInfo.SetConnection(gsDBDataSource, "", gsDBUserID, gsDBPassword)
        Next oConnectionInfo
        '-- Set database connection info for each subreport
        For Each oSubreport In oCrystalReport.Subreports
            For Each oConnectionInfo In oSubreport.DataSourceConnections
                oConnectionInfo.SetConnection(gsDBDataSource, "", gsDBUserID, gsDBPassword)
            Next oConnectionInfo
        Next oSubreport
... but in troubleshooting, we've even tried an "overkill" approach and added this code as well:
        '-- Set database connection info for each table in the main report
        For Each oTable In oCrystalReport.Database.Tables
            With oTable.LogOnInfo.ConnectionInfo
                .ServerName = gsDBDataSource
                .UserID = gsDBUserID
                .Password = gsDBPassword
                For Each oPair In .LogonProperties
                    If UCase(CStr(oPair.Name)) = "DATA SOURCE" Then
                        oPair.Value = gsDBDataSource
                        Exit For
                    End If
                Next oPair
            End With
            oTable.ApplyLogOnInfo(oTable.LogOnInfo)
        Next oTable
        '-- Set database connection info for each table in each subreport
        For Each oSubreport In oCrystalReport.Subreports
            For Each oTable In oSubreport.Database.Tables
                With oTable.LogOnInfo.ConnectionInfo
                    .ServerName = gsDBDataSource
                    .UserID = gsDBUserID
                    .Password = gsDBPassword
                    For Each oPair In .LogonProperties
                        If UCase(CStr(oPair.Name)) = "DATA SOURCE" Then
                            oPair.Value = gsDBDataSource
                            Exit For
                        End If
                    Next oPair
                End With
                oTable.ApplyLogOnInfo(oTable.LogOnInfo)
            Next oTable
        Next oSubreport
... alas, it makes no difference.  If we run the report against a database that is different than the one specified with "Set Datasource Location" in Crystal, it fails with nonsense errors 

Answer 1

Thanks for the reply, Ludek.  We have made some breakthroughs, uncovered some Crystal bugs and workarounds, and we're probably 90% there I hope.
For your first point, unfortunately the information on the Oracle 6550 error was generic, and not much help in our case.  And for your second point, the errors didn't have anything to do with subreports at that time -- the error would manifest itself even in a simple, one-level report.
However, your third point (pointing us to KB 1553921) helped move us forward quite a bit more.  For the benefit of all, here is a link to that KB article:
Link: [KB 1553921|http://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/oss_notes_boj/sdn_oss_boj_bi/sap(bD1lbiZjPTAwMQ==)/bc/bsp/spn/scn_bosap/notes%7B6163636573733d36393736354636443646363436353344333933393338323636393736354637333631373036453646373436353733354636453735364436323635373233443330333033303331333533353333333933323331%7D.do]
We downloaded the tool referenced there, and pointed it at a couple of our reports.  The bottom line is that the code it generated uses a completely new area of the Crystal Reports .NET API which we had not used before -- in the CrystalDecisions.ReportAppServer namespace.  Using code based on what that RasConnectionInfo tool generated, we were able gain greater visibility into some of the objects in the API and to uncover what I think qualifies as a genuine bug in Crystal Reports.
The CrystalDecisions.ReportAppServer.DataDefModel.ISCRTable class exposes a property called QualifiedName, something that isn't exposed by the more commonly-used CrystalDecisions.CrystalReports.Engine.Table class.  When changing the data source with our old code referenced above (CrystalDecisions.Shared.ConnectionInfo.SetConnection), I saw that Crystal would actually change the Table.QualifiedName from something like "SCHEMAOWNER.PACKAGENAME.PROCNAME" to just "PROCNAME" (essentially stripping off the schema and package name).  Bad, Crystal...  VERY BAD!  IMHO, Crystal potentially deserves to be swatted on the a** with the proverbial rolled-up newspaper.
I believe this explains why we were also able to generate errors indicating that field names or tables were not found -- because Crystal had gone and changed the QualifiedName to remove some key info identifying the database object!  So, knowing this and using the code generated by the RasConnectionInfo tool, we were able to work around this bug with code that worked for most of our reports ("most" is the key word here -- more on that in a bit).
So, first of all, I'll post our new code.  Here is the main area where we loop through all of the tables in the report and subreports:
'-- Replace each table in the main report with new connection info
For Each oTable In oCrystalReport.ReportClientDocument.DatabaseController.Database.Tables
    oNewTable = oTable.Clone()
    oNewTable.ConnectionInfo = GetNewConnectionInfo(oTable)
    oCrystalReport.ReportClientDocument.DatabaseController.SetTableLocation(oTable, oNewTable)
Next oTable
'-- Replace each table in any subreports with new connection info
For iLoop = 0 To oCrystalReport.Subreports.Count - 1
    sSubreportName = oCrystalReport.Subreports(iLoop).Name
    For Each oTable In oCrystalReport.ReportClientDocument.SubreportController.GetSubreportDatabase(sSubreportName).Tables
        oNewTable = oTable.Clone()
        oNewTable.ConnectionInfo = GetNewConnectionInfo(oTable)
        oCrystalReport.ReportClientDocument.SubreportController.SetTableLocation(sSubreportName, oTable, oNewTable)
    Next oTable
Next iLoop
'-- Call VerifyDatabase() to ensure that the tables update properly
oCrystalReport.VerifyDatabase()
(Thanks to Colin Stynes for his post in the following thread, which describes how to handle the subreports):
Setting subreport connection info at runtime
There seems to be a limitation on the number of characters in a post on this forum (before all formatting gets lost), so please see my next post for the rest....