very slow open rpt file in windiwsXP and Windows Vista

[Former Member]

Dear Sirs, We have a problem. We have a VB6 program with Crystal Reports XI, and every think was ok until some time ago, when we try to open a report the program take to long to open the report. we have made some debug and we found that the problem was open the rpt it seft. It take 2/3 minutes to open the rpt, and from that point was as fast as ever. I dont find any problem on the report. With pc's with windows XP, and windows Vista is too slow but not that slow with windows 2000. I dont have a clue about what the problem might be, can you help us please.

Kind Regars.

Paulo Costa

[former_member183750 · Accepted solution]

Paulo, please let me know the following:

1) Are you using CR XI release 1 or release 2?

2) have you ever downloaded any updates for your version of Crystal reports?

3) Does the VB 6 program work as expected on your development computer?

4) is this an upgrade from a pervious version of Crystal Reports?

5) What are you comparing the load time to? E.G.; where do you see a satisfactory result?

Ludek

[Former Member · Accepted solution]

Hi, Ludek thank you.

1) CR XI release 2

2) yes i have the crystal reports updated

3) yes on the development computer it work fine, and had worked fine as well on the production environment and in diferent's places.

4) No fresh new.

5) Ok ludek in the development it takes 5/7 seconds to open and show the report.

and also in production. but in some others machines with the same informations, it take 3/4 minutes.

we made some diag show the time spent on each code line, and we figure that he takes the 3/4 minutes. Example:

"Global CRP_Application As CRAXDRT.Application

Set CRP_Application = New CRAXDRT.Application

Set CRP_Report = CRP_Application.OpenReport(App.Path & "\Reports\XPTO.rpt")

We have the rpt file on file system.

Thanks in advance

[Former Member · Accepted solution]

Global CRP_Application As CRAXDRT.Application

Global CRP_Report As CRAXDRT.Report

Global CRP_Db As CRAXDRT.Database

Global CRP_DbTables As CRAXDRT.DatabaseTables

Global CRP_DbTable As CRAXDRT.DatabaseTable

Global CRP_DbTable_det As CRAXDRT.DatabaseTable

Global CRP_SubReport As CRAXDRT.Report

Global CRP_Sections As CRAXDRT.Sections

Global CRP_Section As CRAXDRT.Section

Global CRP_ReportObjects As CRAXDRT.ReportObjects

Global CRP_SubObject As CRAXDRT.SubreportObject

Global FRM_REPORT As Object

-

---

Set CRP_Application = New CRAXDRT.Application

Set CRP_Report = CRP_Application.OpenReport(App.Path & "\Reports\XPTO.rpt")

Set CRP_Db = CRP_Report.Database

Set CRP_DbTables = CRP_Db.Tables

Set CRP_DbTable = CRP_DbTables.ITEM(1)

Set cdoRowSet1 = CreateObject("CrystalDataObject.CrystalComObject")

cdoRowSet1.AddField "AA" 'CAMPOS DO TTX

cdoRowSet1.AddRows dados 'CARREGAR ARRAY DADOS

CRP_DbTable.SetPrivateData 3, cdoRowSet1

Set FRM_REPORT = CRP_Report

Load PRD999_REP_VIEWER

PRD999_REP_VIEWER.CrystalActiveXReportViewer1.ReportSource = CRP_Report

PRD999_REP_VIEWER.CrystalActiveXReportViewer1.ViewReport

PRD999_REP_VIEWER.Show

[former_member183750 · Accepted solution]

OK. Let's compare the dlls loading on the good computers and the slow computers. To that end, download the modules utility from here:

https://smpdl.sap-ag.de/~sapidp/012002523100006252802008E/modules.zip

Follow these steps:

1) Unzip the above file

2) On your dev system, run your app and process a report - leave the app running

3) Start modules

4) Go to the File menu and select New List -> Memory Modules

5) Save the file as good.mdl

6) Repeat above steps on the slow computer

7) Save the file as slow.mdl

😎 Expand the "By Process" node and find your app exe

9) Click on the app exe - this will populate the right pane with all the dlls loaded by your app

10) Go to the View menu and select Details. This will show you the version of the dlls loaded

You can compare these manually or let Modules compare for you (Module menu, select Differences)

I suspect the slow computers will have older dlls, so you will have to update those. The latest RDC MSM files can be downloaded from here:

https://smpdl.sap-ag.de/~sapidp/012002523100009381702008E/crxir2sp4_rdc_mm.zip

Ludek

[Former Member · Accepted solution]

Good Morning Ludek, thank you i will do that, but let me let you one think.

i have several diferent computers, some with the old report in CR7, and other computer's with new packges with CRXiR2 and the beavour is the same.

it look likes the program try to find the rpt file (wich is in a local disk), but firts try someother think until a time-out occours and then it open it.

i already try to change the primary dns of the computers to a new Active directory server, to solve some DNS lookup times but nothing changes.

do you never had some problem like it ?

Thanks in advance

Paulo Costa

[Former Member · Accepted solution]

sorry but have have talked to the users righ now, and they told me that during the day it happend to be fast and slow. for instance today at the morning was (WET 8:00) was very slow (4 minutes) with few users and now (WET 12:00) it takes 4 seconds to open the report.

i had tested the data and is not a database problem because even with the data in arrays it take the same time.

Paulo Costa

[former_member183750 · Accepted solution]

OK. That is a very different story now... Not sure if when you say; "i have several different computers, some with the old report in CR7, and other computer's with new packges with CRXiR2", you mean that on some computers you run the same app using CR 7 runtime and on others you run it using CR XI? I'll assume that to be the case.

You mention that you are seeing htis same behavior with CR 7 runtime as well as CR XI runtime? Strange if that is the case. Even stranger, sometimes it's slow, sometimes it's fast? Taking the two points above, I suspect it's environment rather than CR it's self.

We'll have to back up a bit and decide if we want to troubleshoot CR 7 or CR XI. As CR 7 has not been supported for many years, I'd suggest going with CR XI.

Next question. If this is also happening with CR 7 runtime (and therefore assuming the app has been implemented years ago), how is it that these issues have not been noticed until now?

From here, working on the CR XI r2 computers, I want to see the latest runtime installed there. The latest msm files can be downloaded from here:

https://smpdl.sap-ag.de/~sapidp/012002523100009381702008E/crxir2sp4_rdc_mm.zip

It would be a good idea to install latest Service Pack on the dev computer and recompile the app. SP 4 can be downloaded from here:

https://smpdl.sap-ag.de/~sapidp/012002523100006255422008E/crxir2_sp4_inc.exe

Once you are working with the latest, see if you can reproduce the issue on your dev system. If not, redeploy the app. If you start to see issues again, I'd monitor memory issues using PerfMon. Specifically, look at Private Bytes, Virtual Bytes and Handle Count. Also, monitoring Task Manager will be a good idea. on the Process tab, see if there is any process taking up a lot of memory.

Next. In your code I do not see you disposing of the report object (cpr_report = nothing). You should be doing this as soon as you get done with a report object. You should probably be doing the same with the recordset.

Ludek

[former_member11696 · Accepted solution]

Hi Paulo,

For XI R2 check your reports and registry settings. Make sure Verify on first refresh is checked off and Verify StoredProcedure is also checked off.

In the Designer it will be under File, Report Options.

The registry for the RDC may have this key:

HKEY_CURRENT_USER\Software\Business Objects\Suite 11.5\Crystal Reports Designer Component\DatabaseOptions

If not then set the options for the CR designer under this key:

HKEY_CURRENT_USER\Software\Business Objects\Suite 11.5\Crystal Reports\DatabaseOptions

I don't recall what those options were for CR 7.

Also for XI R2 modify this key:

HKEY_CURRENT_USER\Software\Business Objects\Suite 11.5\Crystal Reports\DatabaseOptions - DoAutoSmartLinking = No

This will stop CR from trying to link all tables and field when first opened.

Thank you

Don

[Former Member · Accepted solution]

Hi i have used the debug diag from microsoft and i have found that then delay is occour when caling P2smon.dll , can some one help me.

Thnaks

[former_member11696 · Accepted solution]

Hi Paulo,

It should not be loading that p2smondll. Try renaming it to *.old and test again.

Where is it loading the dll from?

If you had an older verison of Crystal 8.5 we installed our runtime into \windows\crystal folder, rename that folder if it exists also so we don't look there any more.

Also I noticed you are using the old Crystal Data Object Driver. You should upgrade to OLE DB and driver.

Thank you

Don

[former_member183750 · Accepted solution]

The fact that you see p2smon.dll loading tells me that the slow app is not using CR XI. I have never seen CR XI use p2smon.dll. This dll was last used in CR 8.5 and the database engine was rewritten in CR 8 and has not used p2smon.dll since then (but there is always the first time..., been around computers too long to argue otherwise). In any case, have you had a chance to use the modules utility as I suggested in post dated Sep 16, 2008? If not, please do so and compare the dlls on the dev system as opposed to the slow computer.

Ludek