Skip to Content
0
Former Member
Aug 01, 2011 at 04:05 AM

Database Login dialog presented in reporting application when report select

34 Views

I apologize for the length of this question but I wanted to provide some background.

My initial problem began after updating an existing stored procedure, used for an existing report, to return an additional, new column of data. I went through my normal steps of updating the stored procedure, creating it in SQL Server 2005, pulling the report up in Crystal Reports Designer and performing Verify Database. Usually, this is all I need to do to get Crystal to recognize the new column.

All was good at this point until I ran the new report within my application. I am being presented with a Database Login dialog. Event with it being presented, entering the correct password (even though it is showing asterisks in the Password field) is not accepted.

I have tried removing the connection and creating a new one including specifying the data source again. I can successfully update the data source. However, when I now run Verify Database, I get the following error:

Database Connector Error: Unable to obtain error message from server.

In the past, Iu2019ve logged off the server and logged back on in the designer to create a new connection. This has usually solved the problem related to the message. However, it isn't working to eliminate the login request for credentials.

My application is written in C# (VS2003/.NET Framework 1.1) and has been in use for about 3-4 years. I use CR XI Release 1 SP3. An ODBC (RDO) connection is used with the data source information retrieved from the appSettings of a .config file. The DSN parameters are set in a ConnectionInfo object which is applied to each table (there is only one) in the reportu2019s Database.Tables collection after the Load method as shown below:

TableLogOnInfo logonCrystal = new CrystalDecisions.Shared.TableLogOnInfo();

ConnectionInfo crConnectionInfo = new ConnectionInfo();

crConnectionInfo.ServerName = ConfigurationSettings.AppSettings.Get("DSN");

crConnectionInfo.DatabaseName = ConfigurationSettings.AppSettings.Get("Database");

crConnectionInfo.UserID = ConfigurationSettings.AppSettings.Get("UID");

crConnectionInfo.Password = ConfigurationSettings.AppSettings.Get("Password");

foreach ( Table myTable in extReport.Database.Tables )

{

logonCrystal = myTable.LogOnInfo;

logonCrystal.ConnectionInfo = crConnectionInfo;

myTable.ApplyLogOnInfo( logonCrystal );

}

Once this is done, the parameter data for the stored procedure is loaded using the SetParameterValue method and the CrystalReportViewer objectu2019s ReportSource property is set with the ReportDocument object.

The stored procedure can be run successfully without error. As noted above, it is the same stored procedure that has been run for a number of years but is now returning an additional column. I have monitored the interaction between the Crystal Designer and the stored procedure using SQL Profiler. Iu2019ve also done this while the actual report is running from the application. I havenu2019t seen anything wrong or unexpected.

Reports that havenu2019t been changed continue to run successfully and as expected. The last time I updated a report was about two months ago and did not encounter any problems. The updated report had a similar change u2013 a new column was added to the stored procedure and the report definition was changed to utilize the new column. No difficulty was encountered at that time.

All of this testing and results noted above occurs on my development system which runs on Windows XP Pro SP3. I have not deployed this change to the production environment yet.

I have run the Modules application and have an .mdl file. The versions of the CrystalDecisions DLL files seem to be 11.0.9500.nn where nn is 50, 55, 60, 63 or 65. There are three files with a version of 11.0.0.1282. My GAC shows the assembly version as 11.0.3300.0. I also have GAC assemblies for Crystal Reports XI Release 2 which show as 11.5.3300.0 (I believe this is correct). I had had Release 2 earlier but uninstalled it.

I have also run Microsoftu2019s Process Monitor to capture information for both this failure condition and another report that is successful. I can see the registry access for the ODBC retrieval for the data source. It fails for the report I recently modified but succeeds for an older, unchanged report.

Let me know if there is additional information required.

Thanks,

Jim