Problem with Cyrstal Report 9.2 accessing SQL Ser.

Please start any new threads on our new site at https://forums.sqlteam.com. We've got lots of great SQL Server experts to answer whatever question you can come up with.

All Forums

Development Tools

Other Development Tools

Problem with Cyrstal Report 9.2 accessing SQL Ser.

Author

Topic

Aamir
Starting Member

14 Posts

Posted - 2004-07-01 : 03:04:11

I am facing a problem with SQL Server and Crystal Reports 9.2. I have created a report based upon a view. When i run program from VB it show following message.

Logon Failed
Detail: ADO Error Code 0x80040e4D
Source: Microsoft OLE DB Provider for SQL Server
Description: Logon Failed for user sa
SQL State: 42000
Native Error: 18456

When i run the same report made in crystal 8 it works without any error. I will be appreciated for the solution.

SoftGuru

OmarFrancisco
Starting Member

1 Post

Posted - 2004-07-22 : 19:08:31

I Have the same problem, but it apper in some report of crystal 9

Logon Failed
Detail: ADO Error Code 0x80040e4D
Source: Microsoft OLE DB Provider for SQL Server
Description: Logon Failed for user 'currentuser'
SQL State: 42000
Native Error: 18456

bdekorte
Starting Member

2 Posts

Posted - 2004-08-11 : 10:26:53

same problem.

funny as it sounds,
try removing all parameters from report.

this worked for me from VB 6.

Obviously, this is not a solution, as you probably need the report parameters. I made a blank report with no tables, it works. Then added tables, still worked, then added a parameter, and displayed that parameter on the report or in any formula field, i get this error. when i removed all references to that parameter in the report (without actually deleting the parameter, it worked again.

bdekorte
Starting Member

2 Posts

Posted - 2004-08-11 : 11:59:02

FYI,

I was able to resolve this problem by using
the ODBC (RDO) connection option when designing the report
using the "trusted connection" option.

I of course had to set location for every table, stored procedure, etc., but only in design-time. no run-time code was necessary other than calling .Open(ReportFileName) method and then, in my case, calling .ReadRecords and then .PrintOut.

Hey, at least it is a solution. I would haave preferred a DSN-less connection.

my ODBC DSN was setup using windows authentication.

Subscribe to SQLTeam.com

SQLTeam.com Articles via RSS

SQLTeam.com Weblog via RSS

- Advertisement -

Resources