[RESOLVED] Problems w/Crystal Reports XI and 64 Bit machines?

Does anyone know if there are any known printing issues using CR XI on a 64 bit server? Our applications can preview a CR Report but it won't allow it to print a hard copy.

Thanks,

In order to add more information to the description of this problem, note that I am experiencing similar, if not the same, problem. I am using Visual Studio.NET coding in C#, and Crystal Reports does not print on any of our 64 bit machines, neither the thin clients nor the work stations. The print dialog window does not display and the only visual feedback seen is the button being clicked. However, I am able to EXPORT my report to PDF format, then open that report with Acrobat version 8, and it prints just fine. I am still searching for a remedy, but I have noted another report of the same problem at this link. http://bytes.com/groups/net-vb/75911...rystal-reports

I couldn't find an acceptable solution offered as a reply, but one may appear there eventually. If I find a solution, I will post the information here.

I have overcome the problem I had with Crystal Reports not printing on 64 bit machines, but I was using VisualStudio .NET 2005 with CrystalReports Basic 2005, and I couldn't get any success until I installed VisualStudio .NET 2008 with CrystalReports Basic 2008, though I now believe that I could have achieved success by an upgrade to CR Ver. 10 alone. (CrystalReports Basic 2008 corresponds to CR Ver. 10.) Below I describe what I did.

First, I tried to simply target 32 bit machines, (x86 platforms), in my configuration, but then I received an error at runtime that appeared to be the same as an error I saw reported online while researching this problem, so I checked for that error message online. Unfortunately, the reported solution for that error was what I had just done, that is target 32 bit machines in my project configuration, so that was of no help to me. However, if you are already using VS .NET 2008, this will likely solve your problem, without further need to tweak your application.

Since the above solution was reported as effective for applications using VS .NET 2008, and since I had that option available to me without additional cost, I decided to try upgrading. I ran into some problems here, but if you know to do some things in advance, you can avoid them. When I first converted my project, (be sure to work on a COPY, which is detached from SourceSafe), some references to paths to the older version of Crystal Reports were present in the converted project, as well as certain references to older Microsoft DLL's and the like. So before you convert the project to VS .NET 2008, open the project in VS .NET 2005, but do so only AFTER you have installed 2008, since at that time you will be able to point all your references to the later versions, (for some reason, I was unable to point the references to newer versions after conversion). While you are doing that, you might as well go ahead target 32 bit platforms using VS .NET 2005. Make sure that you target 32 bit platforms for EVERY project in your solution, if you have several projects in your solution like I do.

At this point, your Visual Studio 2005 solution just might work, but I didn't check, so I can't say for sure. However, I did note that the only thing I must do on users’ computers, (to get my application to work properly with my final executable), is installation of the new CrystalReports for 32 bit machines, which my setup file creates. If you choose to upgrade your application to use .NET Framework 3.0 or higher, then you likely will have to install that upgrade as well, but I chose to stick to .NET Framework 2.0.

If you convert your solution to VS .NET 2008, like I did, then when you open the solution in VS .NET 2008, check all your configuration settings for each project in your solution to ensure that you are indeed targeting x86 Platforms, (and in my case, .NET Framework 2.0). Unfortunately, you will still need to install the later revision of CrystalReports for x86 Platforms. Note that my setup file also created a CrystalReports for x64 Platforms, which I chose not to install, and I have encountered no further problems.

Because my users do not have enough privilege on their own machines to make these installations, it is sort of a pain for me, but if each of your users have full installation privileges, they can simply click the provided CrystalReports for x86 executable, (created by your own setup file), and make the installation themselves, and then all they need to make the application run is for you to provide them with a new executable to overwrite the older version, since all other prerequisites are already installed.

One point worthy of noting is that Microsoft has chosen to no longer allow you to code your setup to check for existence of MDAC 2.8 and automatically install it if needed:down:, so if you have that as part of your application, save the MDAC2.8 directory, (containing the executable for this purpose), so that you can make the installation as needed, if your setup barfs due to it not being present. If you don't save the directory outside of your solution's reach, the MDAC2.8 directory (along with the executable it contains) will be deleted when you rebuild your setup.

Another problem I encountered when installing VS 2008, which you may or may not encounter, is that I was totally unable to Install using Typical or Full installation, since every time it got to the installation process for SQL Server 2005, the installation barfed due to "User already exists". What user?:confused: Microsoft apparently decided I don’t need to know.:mad: So if it already exists, what's the problem? Shouldn't installation just continue? Yes, of course it should, but that's Microsoft for you!:rolleyes: And why do I need SQL SERVER installed anyway? My problem may have been related to my previous installation of SQL Server in order to try out some Server Side code, which I decided against using, since I am seeing much the same benefit by deploying the application on a Thin Client Server, which is the 64 bit machine that caused me to run into this problem in the first place.

Good luck in your attempt to fix this problem for your application. I hope that I have communicated potential problems you might run into along the way in a clear enough fashion that you will be able to avoid the additional problems I encountered.

SD,

Thanks for the update. Currently, we aren't having any issues with this anymore. To be truthful, I don't even know what the work-around was to our solution. However, I will keep your solution on hand if this ever pops up again. We're still on VS 2005 with no intentions of upgrading to 2008 for awhile yet.

Thanks again,