Some WS do not return subreport data in compiled crystal 7

[MacolaHelp]

This is wierd. I have a compiled v7 report with one subreport installed on a network drive on NT server runinng pervasive 2000i & using the pervasive odbc data source. The report began as the ICR pp04p1, but has had a number of databases attached & has only the remaining component detail 5 report. 5 workstations can run it with no problem. 4 of them are win98, 1 is win2k. 1 of the 98 workstations that can run it successfully has 2 local printers attached, the others use network printers only. The report is going to a multi tray lexmark laser printer to tray 3, printing to prestacked color paper, 3 copies (so we get one of each color).

2 workstations that need to print this report cannot. They are win98. They print the 3 copies of the main report (which contains my header information), but will not print the subreport detail which contains my component information for my work orders. One of the WS w/problems has a local printer, the other does not. I have tried compiling this report with no printer, the default printer (tray 1 plain paper to the network lexmark laser) & the actual tray 3 that it should go to. None of these solutions work. The workstations that can't generate the subreport data hesitate & indicate they are accessing the database as if they are trying to get the subreport data, but end up only bringing the main report data into the viewer.

I have reinstalled the pervasive & crystal & macola clients on my problem workstations. I have loaded qedllmgr & compared the dlls on a working workstation to one that doesn't. I have re-registered the crviewer, etc. BTW: I can only get my 3 copies if I send the report to the viewer first & then select the 3 copies on the printer. If I try to send direct to the printer I only get 1 copy.

This has been a problem for 3 months & haven't had much success with anything so far. Anyone else seen this before?

 

[kscheeler]

Can you run the subreport as it's own report on the problem workstations?

Kevin Scheeler

 

[kscheeler]

Can you run the subreport as it's own report on the problem workstations?

Does it work to the screen/printer when opening the report in the designer on one of those workstations?

Kevin Scheeler

 

[vbajock]

Being win 98 I would suspect some type of DLL versioning problem. There is a final rollup service pack for 98 on the MS website, you might try applying that. There is an underlying MS system called MDAC that also should be update to at least version 2.6.

 

[MacolaHelp]

I don't remember if I tried running the subreport independently on these problem workstations. I did think of trying that this morning & will try it when next there on the 14th. The crystal report designer also does not return subreport information on my problem workstations. I'll have the network fellow verify that all service packs for 98 are applied & put the most current mdac on them as well. However, I have heard some precautions about using mdac > 2.5 w/Macola. I once had to install 2.7 to get a win2k machine to run at one site, so I suspect the mdac version, as long as 2.5 or above, should be fine, even though some advise against it. If it fixes this nagging crystal problem, I'll be happy to use it as a solution.

 

[vbajock]

We installed Office XP, which automatically upgrades MDAC to at least 2.6 on about 30 computers at a client's site three months ago. Have had zero problems, and they are running tons of custom code and third party add ons.

 

[MacolaHelp]

Updated info: I went to this site on the 14th. I updated starship to version 8. Starship installs mdac 2.6 & will reboot a workstation that doesn't have it installed. Starship installed on all workstations (those that work & those that don't just fine, no errors).

Crystal sent me a utility called "modules" that detects what modules processes are loading. You can compare/report differences on workstations that work vs those that don't. The differences on the workstations that won't run the compiled crystal (crrun32.exe) are:

implode.dll
msvcrt.dll
oleaut32.dll

I can copy implode.dll from a functioning workstation & it doesn't fix the problem. I cannot copy msvcrt or oleuad32 from a functioning workstation, indication that the file is in use by windows, even tho I have used ctl-alt-del end task to all windows programs save systray & explorer.

I have tried to run the crystal subreport by itself, it prompts me for the link to imordbld line # & seq # (this started as generic macola ICR component detail 5 sub report in pp04p1.rpt). After entering the links, it tries to compile & returns a blank screen, just as it does to the main report on these 2 workstations out of others that print JUST FINE. It is maddening!

I also downloaded mdac 2.8 & installed on one of my problem workstations to no avail. Aaaarrrrrgh. Any other helpful hints out there? Doesn't matter what user ID I log onto the network as, either. I have tested with administrator & the local user logon.

 

[dgillz]

Have you posted this in the crystal forums?

I must admit this is really wierd. Also Tori at Exact is the best crystal person there. Have you dealt with her at all?

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[MacolaHelp]

I started w/macola. They had no clue what might be going on. I re-opened the incident after trying to recompile the report on a working workstation w/no printers, default printers, the real printer, etc. Micah & Tori got this module.exe for me to try. I am in the process of sending them my updated info I posted here & have also started a thread on the crystal forum. Someone there suggested the mdac solution. The network fellow & I have tried to chase down anything unique on these 2 workstations compared to the workstations that return subreport data. I've also talked w/a woman here who does crystal reports exclusively as a business & she hasn't encountered this before, either. This client does have a custom VB program that links to Macola & we have a custom VB program to link/sync Macola & Goldmine. BUT, why would some workstations run the compiled report just fine & others not? It must be workstation specific, but this feels like looking for a needle in a haystack.

 

[dgillz]

Were both the subreport and the main report written using the same ODBC datasource? If not, I can see why this may not work on some workstations.

Software Sales, Training, Implementation and Support for Exact Macola, eSynergy, and Crystal Reports

http://www.trianglepartners.com

 

[vbajock]

It sure sounds like a DLL version problem. To copy the files in use, put your source files somewhere on the local hard disk. Boot Win 98 into DOS mode. Use DOS to copy the new DLL's to the Windows system directory.

 

[rosemaryl]

Dear Macola,

Dgilz asked me to look at your problem. The mscrvt.dll and oleaut32.dll are required runtime file of crystal. The fact that it is missing is indicative that these dlls are the problem.

What are the versions of IE on the machines that work and on the machines that do not work? What is the version of MDAC on the machines that work and those that do not work?

Are these dlls included when compiling the report? If not, try recompiling the report and including these dlls and see if that makes a difference.

Also, you might try downloading the dlls from this site

http://www.dll-files.com/

copying them to the correct directory and then registering them. I would rather track down the differences in the machine and get the dlls installed correctly rather than downloading them from here. But, it is an option.

If none of the above offers help, you can always try installing Crystal Reports on the machine, making sure everything runs correctly, and then uninstalling. This often works too.

Hope some of this helps, get back to me on the MDAC and IE versions and we will see if we can solve this.

Regards,

ro




Rosemary Lieberman
rosemary@microflo.com,

http://www.microflo.com

Microflo provides expert consulting on MagicTSD and Crystal Reports.

 

[MacolaHelp]

Rosemary: The dlls in question aren't missing, they are different dates between working & non working workstations. IE is v6, sp1 on all 98 machines. Mdac is 2.6 on all win98 machines & I put 2.8 on one of the problem machines to no avail on the 14th. The 2 problem workstations have both merant & pervasive 2000 drivers & we will remove merant in the next couple of days. We will boot these machines to dos & copy the files windows uses in the next few days. When I compile crystal reports I do not distribute the dlls. I have generally had better success doing the crystal client install from the network crystal directory & running client32\setup.exe. This generally has worked to install all necessary dlls for crystal to operate. Was your suggestion to install the full crystal as a local installation on the C drive on my problem machines? I could certainly try that.

Don: I will verify that the odbc datasource on all clients is the same, but am pretty sure it is. Also, that the data source is the same on the main & subreport. Tho, if this were the problem I think all workstations could not run it.

Kevin: I will also try to run the subreport from the designer on a working machine & see if it behaves the same as a not working machine. I ran out of time for this last week.

vbajock: All 98 machines are patched to the latest service packs etal as of late August/early Sept. mdac is 2.6 on all but 1, which I just tried w/2.8.

Thanks everyone for your help. I hope I can get a solution going.

 

[synapsevampire]

So many coefficients here...

Standardize as much as possible, meaning make sure that you use identical DLL's, ODBC drivers, USER name (admin account for testing), MDAC, etc., wherever possible.

Apply common sense, if a version of a DLL is working on one machine and not another, the DLL probably isn't the problem.

Don rallied plenty of high end help here for you, I'm sure you'll resolve it soon.

Good luck.

-k

 

[rosemaryl]

Dear Macola,

In reading through the posts I thought you stated the dll's were missing, my apologies. I haven't done compiled reports in years since I haven't used version 7 in a long, long time.

Have you tried this. Completely uninstall Crystal from the offending machines(s), delete the windows/crystal folder. Make sure all registry mentions of crystal are totally gone.

Reboot.

Redo the Crystal Client install. Did this make it work?

If not, I would then remove everything again and try a full local install of Crystal on the machine and see if it makes a difference.

The problem with dll hell, is that you don't know why there is a difference. I would try to track that down.

Copying the files at the dos level sounds like the easiest thing to try first and then go to removing and reinstalling. Of course, since the dll's are different there might be an application that requires them that will then "break".

Good luck and keep me apprised.

ro





Rosemary Lieberman
rosemary@microflo.com,

http://www.microflo.com

Microflo provides expert consulting on MagicTSD and Crystal Reports.

 

[vbajock]

I was under the impression from previous posts that the DLL's that you are unable to copy over have older dates than the ones on the machines that are working. Is this not true?

 

[MacolaHelp]

Rosemary: I will try your suggestion on uninstalling the crystal client if the dll copy doesn't work. And, then trying to install the full crystal suite on the local machines that don't work.

vbajock: you are correct that the workstations that don't produce subreport data have older dlls of the 3 I mentioned on this thread compared to a similar workstation that DOES return subreport data. We are unable to copy them because a bunch of windows processes are using the dlls. So, we will try the boot the machine to DOS from a floppy & copy the correct dlls from a working machine onto the "naughty" machine in addition to the other things we've identified that make these 2 machines different from the 3 other 98 machines & 2 win2k machines that behave properly.

Again, I appreciate everyone's ideas here. It seems that anything is worth trying.