Database Logon Failed – only on one of two identical servers

    I have a Windows application (not web-based) that is used to run and export Crystal report files to PDF.   The application runs fine in both my dev and test environments locally, and it is also running smoothly on my client’s production environment.  The client is not trying to set up a fresh Test environment, and we are encountering the “Database logon failed.” error.  I don’t have direct access to the servers, but for everything I can think to check, everything appears to be identical in the two environments.  I’d welcome any suggestions on what to try, as I’ve exhausted the things I can think to check to find the differences.

    Development:

    Application written in VS2010, with runtimes installed with the proper install package, not just running the msi, per instructions.   It is compiled with the platform set to “Any CPU”.

    The Crystal rpt’s in use are older Crystal XI R2 files that were inherited from an older system.  They point to a specific ODBC name, but the database that that ODBC is set to changes at run-time (because we could be running the same report against one of a number of db’s).  I found during development that I had to modify the report connection’s “Use DSN Default Properties” setting to “true”, but they’ve otherwise seemed to run smoothly up until now.

    Deployment Environment:

    Both the working and not-working environments are running the application on a Windows 2012 R2 server (64-bit) and hitting a SQL Server 2008 R2 database.  The Crystal 64-bit runtimes are installed.  Both ODBC’s are pointing to a SQL Server driver version 6.03.9600.17415.  They were set up in the 32-bit ODBC manager, but show as 32/64-bit so I presume there isn’t a clash there (or there isn’t in production, anyway).

    The basic code used to generate the report:

    reportDocument.Load(rptFilePath);

    reportDocument.SetDatabaseLogon(strUser, strPwd);

    CrystalDecisions.CrystalReports.Engine.Tables tables = reportDocument.Database.Tables;

    connectionInfo.ServerName = “MyODBCName”;

    connectionInfo.DatabaseName = strDB;

    connectionInfo.UserID = strUser;

    connectionInfo.Password = strPwd;

    foreach (CrystalDecisions.CrystalReports.Engine.Table table in tables)

    {

        TableLogOnInfo tableLogonInfo = table.LogOnInfo;

        tableLogonInfo.ConnectionInfo = connectionInfo;

    }

    reportDocument.SetParameterValue(0, myParameterValue);

    reportDocument.ExportToDisk(ExportFormatType.PortableDocFormat, pdfFilePath);

    I have a Windows application (not web-based) that is used to run and export Crystal report files to PDF.   The application runs fine in both my dev and test environments locally, and it is also running smoothly on my client's production environment.  The client is not trying to set up a fresh Test environment, and we are encountering the "Database logon failed." error.  I don't have direct access to the servers, but for everything I can think to check, everything appears to be identical in the two environments.  I'd welcome any suggestions on what to try, as I've exhausted the…

    Database Logon Failed - only on one of two identical servers

    Very Helpfull

    User Rating: Be the first one !
    Add Comment
    1 Answer(s)

      We resolved the problem – logging here for posterity.

       

      I didn’t specify in my original post, but my Windows app was running as a service.  The client had a specific user set as the account the service ran under.

       

      We had found in setting up their production environment that the reports only seemed to work if we created the ODBC entry as a “User DSN”, and she happened to be logged into the server as that Service Owner user when she created it.  In her test environment, she created the User DSN when logged in as the wrong user.    Once we logged in as the “Service Owner” user and created the User DSN under that account, it worked fine.

       

      I’d be curious if anyone has any thoughts why a Service DSN wouldn’t work in this scenario, but otherwise, the issue is resolved.

      Add Comment

        We resolved the problem – logging here for posterity.

         

        I didn’t specify in my original post, but my Windows app was running as a service.  The client had a specific user set as the account the service ran under.

         

        We had found in setting up their production environment that the reports only seemed to work if we created the ODBC entry as a “User DSN”, and she happened to be logged into the server as that Service Owner user when she created it.  In her test environment, she created the User DSN when logged in as the wrong user.    Once we logged in as the “Service Owner” user and created the User DSN under that account, it worked fine.

         

        I’d be curious if anyone has any thoughts why a Service DSN wouldn’t work in this scenario, but otherwise, the issue is resolved.

        Add Comment

        Your Answer

        By posting your answer, you agree to the privacy policy and terms of service.