Does changing report connection at runtime require the same user/pwd used at design time?

Question

I've recently integrated Crystal 13 into a web service to provide HTML reports served up within our web application.  Sometimes reports would work and other times they would fail when attempting to connect to the database.  The ConnectionInfo associated with the tables referenced in the reports bore the account info used at design time (in the Crystal IDE), what ever connection was set as the Datasource Location, this would include the server name, database name, and other attributes of the connection.
I found that any changes I make to table, sub-report connection info have no affect unless the UserID and Password match the UserID and Password saved with the report during design time.  While generally searching online, I came across several references to this being and issue or suggestion when database connection problems dynamically running reports.
If this is by design?
How would I support customers who want to use my reports, but also require that they manage the db access accounts?
Thanks,
Jeff

Answer 1

Hi Brian, thanks for the response. 
It does make sense that subreports would not necessarily be constrained to the same connection as the container report, and the designer would not persist a password for any stored connection.
I'm on Windows 7 and up, Crystal 13 runtime, C# web service, sql 2008 r2 and up (native client).
After loading the report source, I call ReportDocument.SetDatabaseLogon to set userId, password, serverName, and databaseName pulled from web.config.  I then pass the connection info and the ReportDocument to a recursive call that applies the connection info to each table in the report and each table in any subreport.
Based on your description, it sounds like I may be missing, and require, the SetDatabaseLogon call on each subreport (ReportDocument).
This seems to ring true and I think coincides with your description.  Would you agree?
Thanks,
Jeff