SSL Security Error

[Former Member]

I have had a look through the forums for errors around ODBC connections but none quite match my problem, but I have tried some fixes, but to no avail.

We are having issues with Crystal Reports 2011 on a Windows 7 32bit machine with SQL Server 2008 (all installed on the same machine)

We have an existing ODBC System DSN created that we can use from within other applications to connect (for example, we can use the connection within MS Access to successfully connect to the SQL Server and browse the database).

The connection is set up to use Windows Authentication.

The exact error we get is: \[Microsoft]\[ODBC SQL Server Driver]\[DBNETLIB]SSL Security error. We are using the ODBC(RDO) connection type to reference the DSN which uses the SQL Native Client 10.0 driver (we have tried the SQL Server driver as well).

We have also tried deleting old certificates on the machine that have expired (As that was identified as a potential problem in other SQL Server forums), and we have looked at the various registry fixes that are out there.

The issue is still around with CR2011 SP1.

Any ideas would be greatly appreciated!

Cheers!

Jono

Edited by: Jono Stewart on Sep 14, 2011 11:38 PM

[former_member11696]

Hi Jono,

What is the error you are getting?

Are these old reports or new reports? What happens if you log onto the server first using Trusted Authentication checked on and then open a report and set location to the existing connection?

The User account you are logged into the local PC, does it have read/write access to the database? I assume you have enabled/added your user account to MS SQL as well as enabled both MS and Domain Authentication.

If you use Profiler and do you see crw32.exe trying to access the DB? If so what is it logging or reason why it's not allowed?

Don

[Former Member]

The error is in my first post. There is nothing in the error log that gives any more information.

It's not reports - we can't even connect to the database. I am not sure what you mean by logging into the server first... the question states that everything is installed on the one machine. I can happily log into the database using the existing DSNs set up, and I can use Management Studio with the local windows account.

The user is set up as dbo. I want to use Trusted Connection on the connection so there is no SQL Auth on the database - only Windows Auth. We won't be setting up mixed mode authentication.

I haven't had a look at profiler, but I more than likely won't see anything other than an auth failure if it can't even connect to the DB.

Edited by: Jono Stewart on Sep 18, 2011 10:06 PM

[former_member11696]

Hi Jono,

I meant if there was any errors reported by Crystal, the error you are getting is being passed through Crystal from the Client, if the error is happening when trying to connect through CR..

So in your DSN do you have Trusted Auth enabled also? Seems to me it a DSN configuration issue.

I suggest you post to Microsoft and ask them.

You may want to run Process Monitor also to verify what MS Client dll's are being used.

I believe you need to use either 32 or 64 bit client Tools and others have noted issues that the order of both 32 and 64 bit Clients makes a difference. PM should show you which MS files are being loaded when you run the report in CR.

I haven't had any problems going to 2008 with either 32 or 64 bit so I haven't looked at the details of which MS files are being used.

Don

[Former Member]

Nope - there are no Crystal Specific errors, but like I said, we can use the DSN with other applications just fine. It's definitely an error being passed from SQL Server, but it's only Crystal that has the issue, which makes me think it's a connector driver issue of some sort.

I have been through the MS forums where people are experiencing the error already and have tried all the fixes I could find. The last port of call was the SAP forum.

Everything is exclusively 32bit.

We have managed to get it working with a fresh install of Windows 7 and SQL Server 2008, so I guess we will just go with that. It would have been nice to work out why it was happening on this particular machine, but there is just no more time to spend on the issue.

[former_member11696]

Hi Jono,

Very interesting.... CR simply uses what is available and follows what ever configuration it's given.... I've run into issues like this also and I went into the Management Studio and check on all options for read/write that MS would allow me to do under that Admin account for every Table and database. It finally worked but not exactly sure which one did the trick....

I'm wondering, because MS changed/altered Permission on the SA account if maybe you have some Verify Options in the Report enabled? Or could be one of our Verify registry keys.... hard to say exactly.

If you want to continue trying to find the cause then....

We do have a crlogger.dll which is our database logging dll and it will generate logs with details on every API we are using and passing to the client.

Search your PC for crlogger.dll, if it's there you can try adding these 3 variables to your System Environment variables:

LOGGING_DIR = c:\logging

LOGGING_ENABLED_ASSERT = 1

LOGGING_ENABLED_RUNTIME = 30

To disable logging just rename the dll.

In the logs you'll see what CR is doing.

I have not tried this with CR 2011, I have done it with CR for VS 2010 ( runtime for CR 2011 ).

Don