cancel
Showing results for 
Search instead for 
Did you mean: 

Searching for Crystal Reports 11.5 Patch linked to in previous post

0 Kudos

Current Verions: Crystal Reports 11.5.12.1838

New Data Provider being used: MSOLEDBSQL

Old Provider: OLESQLDB

Problem encountered: Some seems to run as expected (more testing needed), A specific group of reports exhibit exactly the same condition described in this previous post

The very last post from Balorm provides links to access what he had found.Under the highlighted Red area list the R2A SP6 incremental that I believe he was speaking of. Following the link returns a not found. It appear that in the post referenced above the link to access the update there was discussion, specifically a post by Don Williams on Sep 21, 2009 at 04:00 PM which acknowledged a changed needing made in CR.

I understand that some of this discussion is related to person of the original post using a different data provider (SQL Native Client 10). They mentioned using the DataTypeCompatibility option as I have having no affect. Being that the situations are VERY similar in nature and the outcome the original poster and we are encountering I was hoping this may be a valid alternative for us as well.

Could a moderator please review this to see if the patch may work for Microsofts MSOLEDBSQL driver as well and possibly provide us knowledge of access and requirements.

Accepted Solutions (1)

Accepted Solutions (1)

0 Kudos

Hi Jamy,

Ah, that's the problem... As of CR 2008, next version after CR XI R2, we no longer install craxdrt.dll, the COM RDC Report engine. We only install the Embedded Report Designer craxddrt.dll into the VS IDE, and we don't install it with any of our runtime.

As for TLE 1.2 I wrote a KBA on how to:

2269180- Disabling TLS 1.0 may cause Crystal Reports Designer and .NET application to fail to connect to your MS SQL Server Database 2012/2014

So why it partially works using the old MDAC Client I don't know, likely due to simple tables etc.

When MS created the SQL Native 11 client they renamed the dll, CR XI R2 does not know of this change, we ahd to update our DB drivers so it did not use the Generic Join types, which may explain why some reports work.

To get CR Reports to recognize TLS 1.2 and the Native 11 client you have to manually update each report to fully support TLS 1.2.

So why it works on your Dev PC is likely because it's all there, for the runtime we don't distribute craxdrt or craxddrt dll's so the app will never work. And you are no longer Licensed to distribute the RDC and Viewer.

Only option is to upgrade the CR Parts of your app and use the CR for VS .NET runtime. There is no direct conversion from the RDC to .NET.

To help you convert have a look at the Printer and Parameter test app's on the WIKI, link above.

Your only option is to delay your release and upgrade your app to use CR .NET..

Good luck

Don

Answers (1)

Answers (1)

0 Kudos

Hi Jamy,

You are using the last patch CR XI R2 released.

There is no fix for XI R2 for that OLE dB issue, it was fixed in CR 2008 and above.

Time to upgrade to CR for VS, works with VS 2010->2019

https://wiki.scn.sap.com/wiki/display/BOBJ/Crystal+Reports%2C+Developer+for+Visual+Studio+Downloads

As noted, the reason is doesn't work is because Microsoft changed the behaviour after XI R2 ended patch cycle so it will never work for you.

Only option is to upgrade CR and runtime or use ODBC.

I see you also tagged TLS, you'll never get that old MS OLE DB Provider to work with TLS1.2, it does not support it. You need to upgrade to MS SQL Native 11 client to use tls 1.2.

Don

0 Kudos

Don,

I understand and respect your recommendation, being a developer I understand the proper course to be taken. Management well... they see things differently.

Please hear me out on the strange situation I am running into...Please just indulge me, I realize there are a lot of variable that can cause environments to behave differently.

Understanding that the MSOLEDBSQL provider mentioned in my original post ended up causing the same result as the post mentioned previously at previous post. I substituted the SQLNCLI11 (18.2) x86 for my provider in the connection string for both my VB6 and the reports that run from it. This is in my dev environment (Windows 10 build 07134.112 and I have CRAXDRT.DLL 11.5.12.1838 installed. From this laptop I can connect (no RDP) to a Windows Server 2016/ SQL Server 2016 having TLS1.2 on TLS1.1, TLS1.0 off, and run the report without any problems. I can also run the same report without issue on a Windows Server 2019/ SQL Server 2019 having TLS1.2 on TLS1.1, TLS1.0 of.

I have checked that all source code is the same when uploading to the build machine. No differences in source code. Using Installshield and CR merge modules. The final installed product has CRAXDRT.DLL 11.5.10.1263. Installing this on another Windows 10 computer, the Windows Server 2016, and the Windows Server 2019 have been checked for the proper version of the SQLNCLI11 and in all instances, the app runs but certain reports having the problem mentioned in the previous post listed above all fail the same way.

My laptop is the only machine it works from and I have validated, or at least think I have every version of filetype involved the only difference seems to be the merge modules providing the older runtime. When I initially ran it I thought I had found a valid solution.

Is it possible the runtime difference is the cause?

Right now we are very limited in time and since my plan above did not work, we are reverting back to MSOLEDBSQL and testing the reports with the known problem and converting the datetime data types to varchar to circumvent it. I am just concerned that we will run into another unknown issue that we won't find a workaround for.

Please review as soon as possible within your convenience. Thank you, Jamy