Crystal 9.0 VB6 Runtime Problem 1

[mrf3000]

Hello,

Hoping someone can help me. I have a vb6 app using the crviewer to display an ado recordset set in code. The report was designed using a TTX file. There are two detail sections....one for each page of the report. Let's call the first the invoice and the second the letter. Well the first invoice prints fine and then the first letter but then when you go to the second invoice, the viewer comes up with an error as follows: "Unkown query engine error"...now the second letter prints as well as the 3rd,4th,5th, etc.....the only ones that don't print are the 2nd and greater invoice. I've tried changing the query with and without a "where" statement and it seems that the error is coming from the report design, but I can't figure it out. I've tried updating the client computer to CR9 SP2 and the varios hot fixes. This does NOT occur on the development machine only on the runtime machine. As far as Crystal says, the TTX file does not need to be in the exact order of the ADO recordset as long as the fields are named. The only time you need the order the same is when you map fields by ordinal position in the registry. Like I said, I have no idea why this error is occurring and any help would be appreciated.

Thanks,
mrf3000

 

[FVTrainer]

Are you using the ReadRecords method of the report object?

You code should look something like the following (assuming an external rpt file instead of a dsr inside vb):

Dim crApp as New CRAXDRT.Application
Dim crRpt as CRAXDRT.Report

Set crRpt = crApp.OpenReport("myreport.rpt&quot

crRpt.Database.Tables(1).SetDataSource rsADO, 3

crRpt.ReadRecords

CRViewer91.ReportSource = crRpt
CRViewer91.ViewReport

If you continue to get errors, I'd be inclined to make sure that the schema of the report (the order as well as names and data types of the fields) is identical to the ADO recordset (as you've hinted that that isn't currently the case).

 

[mrf3000]

FVTrainer,

Hi. The report is actually a dsr inside vb..i've got the code similar with the setdatasource method but I didn't have the readrecords in there. Well, I put in the readrecords as you suggested and I changed the TTF so it correpsonded to the recordset fields. At first, I wasn't successfull and I kept getting GPFs on my devleopment machine and my client machine. Then I fixed the TTF and got it right this time. Made sure it worked on my development machine and then put it on my client machine. Again, the TTF matches up EXACTLY and it still doesn't work. I keep getting Unknown Query Engine Error ONLY on my client machine. I think the problem must be in the report but I can't for the love of God figure out what that problem may be.

Any more ideas?

Thanks,
mrf3000

 

[FVTrainer]

A few thoughts: 1) Do you have any subreports? 2) Are you sure you are distributing all the necessary dll's? (In the case of your app, you definitely need to be deploying crdb_ado.dll.) When reports don't behave on a client but do on the development machine, missing dll's are usually the most common issue. Another possible issue could be that the MDAC versions on the client and development machines are different and that is somehow creating a problem for crystal.

 

[mrf3000]

FVTrainer,

1. No subreports.
2. crdb_ado.dll is installed and reged on client machine
3. Installed MDAC 2.7 as on Development machine and same error.

I can't help but think this is a bug in CR9 and like I said before I've updated the client files to the latest cr9 service pack.

I am at a loss!

Thanks,
Marc

 

[FVTrainer]

I'm actually inclined to think it's not a Crystal bug, for the simple reason that you are trying to do something that is really basic and CR 9 has been out long enough for this issue to have been brought to Crystal's attention if a bug really exists (assuming it's not some obscure issue related to something like an out-of-date dll). However, it certainly could be a bug...

Can you verify which line of code is generating the error? Specifically, I would be interested to find out if you get the message before, at, or after the execution of the ReadRecords line. You can use the PrintingStatus object to see how many records are being read into the report, as in:

Debug.Print "Number of Records read: " & crRpt.PrintingStatus.NumberOfRecordRead

Of course, on the client, you'd need to do something like write the result of NumberOfRecordRead property to a file or display it in a messagebox, but I would be interested to see if the error is occuring in the report object or in the viewer.

Another way to test this would be to print the report in lieu of displaying it, as in:

crRpt.PrintOut False

Sorry I don't have a better answer, but the more ways one looks at the problem, the more it can be narrowed down, and perhaps verified as a bug.

 

[mrf3000]

FVTrainer,

Good call.....there were two records in the recordset. I put in a message box for crrpt.printingstaus.numberofrecordsread and it did say 2....Not to mention that when I set the file to PrintOut, it printed correctly all four pages of the document....so I guess the error is in the viewer...the question is where, how, why, when? At this point should I submit a bug report to Crystal? Your guidance is much appreciated.

mrf3000

 

[FVTrainer]

Have you worked with Modules.exe (a Crystal Decisions tool) or any other tool to track what dll's are in memory at any given time? I've been testing an app modeled after your design (as you've explained it) and my results are inconclusive, but there does appear to be a difference in what dll's the Crystal Viewer uses (and when it releases them from memory), and what dll's CRAXDRT uses. In other words, I believe (somewhat against common sense, I might add) that CRViewer9.dll might very well require some dll's that CRAXDRT doesn't. Since you are getting an error message on the client machines, it gives you an excellent opportunity to examine what dll's are in memory (or missing) at the time of the error. I would recommend doing the following to see if you may be missing a dll on the client machines (By the way, you haven't mentioned the OS's in play; are they the same on the development and client pc's?):

On the development machine, run your app (as an executable rather than from within the vb ide) and bring up the report in the viewer. With the Crystal viewer open and showing the report, run modules.exe and look at the dll's listed for your exe. Save the result. Then on one of the client pc's where you are getting the error, run your app to the point where you get the error (don't close the error message box) and then use modules.exe to view the dll's in use by your app on the client. You can then used the saved results from your development pc to compare and see what (if anything) is different about the dll usage on the two pc's. I've tracked down some obscure things (and also stupid things on my part) using this method. It's tedious and there are better tools than modules.exe, but modules.exe is the only one I have, so it's all I can speak to.

 

[mrf3000]

FVTrainer,

Sorry for the delay in responding but with Thanksgiving and the gift of a cold virus I have been a bit incommunicado. Anyway, I did what you suggested and I tracked down 4 dlls which were in memory on the development machine which were not in memory on the client. Incidentally, I developed the reports on WinXP but for these purposes I ran the exe in Win98. Anyway, I copied each dll to the correct folder and voila! I found the key one - crheapalloc.dll. I have no idea what it does or why it wasn't installed using the InstallShield package but once I copied that to the C:\Program Files\Common Files\Crystal Decisions\2.0\bin, it worked just dandy on the client. I then deleted the file just to make sure and it did not work. So that's it! Thanks a million. I would have never thought of a missing dll considering but thinking back on it I created an install package a while back and have made some significant changes in the report structures. So thanks again!