I'm new to crystal reports and reaching out to the experts on this forum regarding an interesting issue that I have encountered when working with Crystal Reports for Visual Studio 2010. Just to give you a brief background on the application I have developed: It is a windows service written using the .NET 4.0 Framework. When the service first starts, it checks the value of a config parameter/ boolean flag (call it the 'UpdateStartDate' flag), which if set to true, then the service updates a custom oracle table (using .NET SQL bind query / variables) with the service start date and if the flag is false, then, as is obvious, the service does not update the custom oracle table. For ease of reference, let me refer to this oracle table as the 'SERVICES' table. Once this step completes, the service then proceeds to run a crystal report and export the report to PDF format which is then emailed a list of recipients. Regarding the crystal report itself, it is designed to connect to multiple (4) oracle tables using 'Oracle server' type connection (to our development database), it has a date range parameter field, and displays a combination of formula and database fields. The multiple tables are appropriately linked using the Crystal reports designer. Programmatically, the following are the steps I follow in generating the crystal report through the service: 1. Create a new 'ReportDocument' object 2. Load the report in question to this object. 3. Remap the database connection information in the report to the database specific to the environment in which the service is running 4. Verify Database 5. Set the date range parameter values 6. Set the export options on the report to PDF specific settings 7. Export the report Now, to the issue: on my development machine (which is a Windows 7 x64 workstation), irrespective of whether the service updates the 'SERVICES' table or not, the crystal report generates just fine and is emailed to the recipients. However, when I installed the service in our TST environment which is a Windows 2008 R2 enterprise x64 server, the crystal report generates perfectly well but ONLY if the 'SERVICES' table is first updated. If the 'service' table is not updated, then on each scheduled run of the already started service, the crystal report fails when executing the 'verify database' step. The exception received is: Inner Exception --------------- Type : CrystalDecisions.CrystalReports.Engine.LogOnException, CrystalDecisions.Shared, Version=13.0.2000.0, Culture=neutral, PublicKeyToken=692fbea5521e1304 Message : Log on failed. Source : CrystalDecisions.CrystalReports.Engine Help link : ErrorID : LogOnFailed Data : System.Collections.ListDictionaryInternal TargetSite : Void VerifyDatabase() HResult : -2147215360 Stack Trace : at CrystalDecisions.CrystalReports.Engine.ReportDocument.VerifyDatabase() at MailingService.GenerateMailing() Inner Exception --------------- Type : System.Runtime.InteropServices.COMException, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 Message : No error. Source : Analysis Server Help link : ErrorCode : -2147483648 Data : System.Collections.ListDictionaryInternal TargetSite : Void VerifyDatabase() HResult : -2147483648 Stack Trace : at CrystalDecisions.ReportAppServer.ClientDoc.ReportClientDocumentClass.VerifyDatabase() at CrystalDecisions.ReportAppServer.ReportClientDocumentWrapper.VerifyDatabase() at CrystalDecisions.CrystalReports.Engine.ReportDocument.VerifyDatabase() At this point, I concluded what it needs is that 'first interaction to the database' just once at service start up and i.e. before any report is generated and this theory works. So, as a workaround, I added a piece of code that at start-up, the service does a simple 'select sysdate from dual' just to satiate this need and now the service is working fine. It bothers me that it is a workaround and leaves me wondering why I should even need to do this. Furthermore, I wonder why the service is exhibiting this behavior in the TST environment and not on my DEV workstation? It is natural at this point to consider the aspect that it may have to do with the fact that the report connection is remapped from the DEV database to the TST database. But what makes this even stranger is that if I set the service connection string on my DEV workstation to the TST database, that works fine in that it does NOT require the workaround. Would love to hear your thoughts. Thanks, Sid
↧