New post
0

Error: Object reference not set to an instance of an object.

We use CRD PremiumX edition. We are getting this error when we try to execute a couple of schedules:

Error Number: 5
Module Name: RunSingleSchedule
Line Number: 3040
Error Description: Destination Error: Email

+++++++++++++++++++++++
Report Processing Error:
Error Description: CrestHoldingsRecTHNNOM:
Object reference not set to an instance of an object.
Error Number: 91
Error Source: ProcessReport
Error Line: 3770
Suggestion: General Crystal runtime error. Please make sure your Crystal Reports runtime files are up to date and correctly registered on the machine
+++++++++++++++++++++++

Immediately prior to getting the error we changed the login credentials (User Id and Password) for all our schedules. All the other schedules are working fine since we changed the credentials, except for these two schedules which give the above error.

If we run the reports directly from Crystal Reports using the new credentials, the reports run fine.

If we change the credentials on the two problem schedules back to what they used to be, they work. It's only when using the new credentials on these two schedules that we get the errors.

We need to change to the new login credentials - we cannot continue using the old credentials.

Would be grateful if anybody can suggest what this error means in the context of the above scenario, and how we can resolve this problem.

Thanks

1 comment

  • Avatar
    Johnathan Lucky Official comment

    Aj1,

    Thank you for logging this query. Give the specificity of this error and your scenario, I recommend having us look into the problem within the confines of a private ticket, rather than publicly on the community forum. It sounds like the problem is likely the report having some form of credentials saved in the Crystal Report itself.
    If you have any trouble creating a support ticket, please inform your account manager.

    Thanks,
    CSS Support

    -Thanks for your response. Since my last post, we started getting the same error even when using the old credentials, so we can no longer run these schedules.

    After that, we have:

    • rebooted the CRD server. This made no difference to the problem.

    • re-saved the reports with the new credentials. Again this made no difference.

    Next, we will try re-creating the schedules in CRD. If this fails we will log a support ticket.

Please sign in to leave a comment.