Help! Printing runs fast on IDE but very slow on executable

[mtl777]

I have a program that prints a batch of records. It runs very fast when I run it in the IDE. But quite surprisingly, when I run the compiled executable, it runs agonizingly slow! It's not the DB access that's slow. There seems to be something going on when the executable program communicates with the printer that is causing a long delay. I am so stumped. Could someone please help me with this issue?

Thanks in advance!

[jdc2000]

Post the code that does the actual printing of the records. Without that, we will be stumped also.

[mtl777]

Post the code that does the actual printing of the records. Without that, we will be stumped also.

Here's the code snippet. It's using Crystal 8.5. You can specify the number of records to print. The loop gets one record at a time and prints it.

Private Sub cmdBatchPrintCMS_Click()
Dim Num As Integer, RecordID As Long

MousePointer = vbHourglass

For Num = 1 To Val(txtNumToPrint)

If deRMS.rsspGetBatchPrintCMS.State <> 0 Then deRMS.rsspGetBatchPrintCMS.Close
deRMS.spGetBatchPrintCMS 'Get one record to print

If deRMS.rsspGetBatchPrintCMS.EOF Then
MousePointer = vbDefault
MsgBox "No more records to print."
Exit Sub
End If

RecordID = deRMS.rsspGetBatchPrintCMS!RecordID
PrintOneCMS deRMS.rsspGetBatchPrintCMS
If txtNumToPrint = 1 Then If MsgBox("Is this a TEST PRINT ONLY? If YES, then Printed Status will NOT be updated.", vbYesNo) = vbYes Then Exit For
deRMS.spUPDATEUB92STATUS RecordID, "SINGLE PRINTED"
txtTotNumPrinted = LTrim(Val(txtTotNumPrinted) + 1)

Next

MousePointer = vbDefault
MsgBox "Printing done."
End Sub

Private Sub PrintOneCMS(ByVal rsOneCMS As ADODB.RecordSet)
Set rpt = New crpPrintCMS1500
rpt.Database.SetDataSource rsOneCMS 'NOTE: This recordset must contain only one record!
rpt.PaperSize = crDefaultPaperSize
'rpt.PaperSource = 1
'rpt.PaperSource = crPRBinAuto 'crPRBinLargeCapacity 'Tray 4 in Kyocera CS 6500i 'was crPRBinUpper
'Setting PaperSource to Tray 4 is hit and miss. Just set it up by selecting Cassette 4 in Printing preferences (printer driver config) so it becomes the default.
'Then don't set the PaperSource in the program.
rpt.PrintOut False
End Sub

[mtl777]

I have identified that the cause of slowness is the statement Set rpt = New crpPrintCMS1500.

I tried placing this statement before the For loop starts so that it's done only once. The program executes fast but the problem is that it prints the same record over and over again. It seems that the SetDataSource method does not load the new recordset. It just keeps the old one and doesn't change. How do I make it change?

And the big mystery is why Set rpt = New crpPrintCMS1500 is fast in IDE but very slow on executable mode.

[mtl777]

I wish someone could help me soon with my question. Anyone please?

[westconn1]

post your updated code

[mtl777]

post your updated code

Here it is. All I did was move the statement Set rpt = New crpPrintCMS1500 to the place before the For loop starts so it gets executed only once.


Private Sub cmdBatchPrintCMS_Click()
Dim Num As Integer, RecordID As Long

MousePointer = vbHourglass
Set rpt = New crpPrintCMS1500 'Slow statement moved here

For Num = 1 To Val(txtNumToPrint)

If deRMS.rsspGetBatchPrintCMS.State <> 0 Then deRMS.rsspGetBatchPrintCMS.Close
deRMS.spGetBatchPrintCMS 'Get one record to print

If deRMS.rsspGetBatchPrintCMS.EOF Then
MousePointer = vbDefault
MsgBox "No more records to print."
Exit Sub
End If

RecordID = deRMS.rsspGetBatchPrintCMS!RecordID
PrintOneCMS deRMS.rsspGetBatchPrintCMS
If txtNumToPrint = 1 Then If MsgBox("Is this a TEST PRINT ONLY? If YES, then Printed Status will NOT be updated.", vbYesNo) = vbYes Then Exit For
deRMS.spUPDATEUB92STATUS RecordID, "SINGLE PRINTED"
txtTotNumPrinted = LTrim(Val(txtTotNumPrinted) + 1)

Next

MousePointer = vbDefault
MsgBox "Printing done."
End Sub

Private Sub PrintOneCMS(ByVal rsOneCMS As ADODB.RecordSet)
rpt.Database.SetDataSource rsOneCMS 'NOTE: This recordset must contain only one record!
rpt.PaperSize = crDefaultPaperSize
'rpt.PaperSource = 1
'rpt.PaperSource = crPRBinAuto 'crPRBinLargeCapacity 'Tray 4 in Kyocera CS 6500i 'was crPRBinUpper
'Setting PaperSource to Tray 4 is hit and miss. Just set it up by selecting Cassette 4 in Printing preferences (printer driver config) so it becomes the default.
'Then don't set the PaperSource in the program.
rpt.PrintOut False
End Sub

[westconn1]

unless you dimentioned rpt elsewhere in the code, i am surprised you do not get other errors each time you try to assign value to rpt properties

do you have dim rpt ..... somewhere in your code?
if not try putting it at the top of the module, before any subs

[mtl777]

unless you dimentioned rpt elsewhere in the code, i am surprised you do not get other errors each time you try to assign value to rpt properties

do you have dim rpt ..... somewhere in your code?
if not try putting it at the top of the module, before any subs

rpt is a public variable defined in the main module. It is used throughout the project for any report that uses Crystal Reports. What should I do in this case?

Thanks!

[mtl777]

No one still has a solution for my problem?

What are the things going on when a Crystal Reports object is created? One of these things is running very slow. Which one could it possibly be?

[westconn1]

are you by any chance, running the vb6 ide elevated and the exe as a std user?
not that i have any idea if this would make a difference to crystal reports, as most here do not use CR, hard to find someone with experience to answer your problem

[Elroy]

Hi mtl777,

Yeah, I don't think we have anything against you. I just think it's a lack of experience with Crystal Reports. I see it mentioned once every blue moon on these forums, but it's very far from a hot topic around here. I can share a couple of things, but I'm not sure either will help.

I primarily use Word and/or Excel to generate all of my reports in my primary application. I use templates (both Word and Excel), and then fill these templates in via automation to generate specific reports. In almost all cases, my clients need to save a copy of the reports that can be reviewed again later. (In fact, many of my clients are entirely "paperless".) Word and Excel are ideal for that situation.

I also occasionally use the VB6 printer objects to print certain "quick" worksheets, but that's only in a few isolated situations.

Regarding both Word/Excel automation and using the VB6 printer object, I've never noticed any difference in speed between the IDE and compiled.

Also, and this is probably particularly unhelpful, but I remember trying Crystal Reports (back when it was still VB4, 1997-98) and we couldn't make it behave. Therefore, we rather quickly abandoned it for other reporting methods. We actually built a working "bridge" between VB and MS-Access, using MS-Access for our reporting (with VB as the front-end). I've always felt that MS-Access had fairly nice reporting capabilities, particularly in those situations where you had to deal with lots of "transactions" such as accounting applications.

So, from the little I know, I'd definitely say it's a problem with Crystal Reports (not seeing, or knowing about, any similar slow-downs in other areas). I forget what the "installation" is for Crystal Reports, but maybe if you try re-installing it, or possibly re-registering whatever OCX files it uses, making sure they're in the SysWOW64 folder of any WIndow 64-bit computer.

Good Luck,
Elroy

[Eduardo-]

As had been said, the reason why you don't get many answers is most likely because almost anybody have much experience with CR here.

What I would do is to try to isolate the situation of the problem. Did you test in different Windows versions: 32, 64 bits, Windows 7, 8, 10?

Did you reinstall the program on the affected machine?
Did you reinstall CR -and VB6- in your development machine (and recompile your program)?

Do you have VB6's Service Pack 6 installed?

These tests is what I would start doing.

[georgekar]

I think in the loop there is no a Doevents or a sleep to pass time to OS to do some work. In the IDE the execution time handled by IDE and this means that some doevents in IDE code pass time for background tasks as those for printer.

[Elroy]

Hi George,

I'm really not sure how Crystal Reports works, but a DoEvents is thread-specific. What this means is that other threads (and other applications) don't care if you have DoEvents or not. The Windows software interrupts will take their timeslices regardless of what your VB6 program is doing. Now, if you do have your program "caught" in an infinite loop, you will certainly be taking some CPU resources, but other programs will still do what they need to (just possibly taking a bit longer).

Also, (without jumping through some very high hoops) VB6 is single-threaded. To me, what that means is that Crystal Reports should go do its thing whenever any of its members (methods and properties) are called, with no need for any DoEvents. The thread should simply go there and do the work.

Now, here's a scenario that "might" explain things (but I highly doubt it because three things would need to happen and I don't think any of them are):

1. If Crystal Reports were designed sophisticated enough to run in a separate thread from VB6 (which I highly doubt).
2. If the VB6 program were doing some long loop after Crystal Reports were called.
3. If this long loop were being executed only when compiled (and not in the IDE).

Then, you might see the slowdown about which mtl777 is discussing. But this all seems highly unlikely.

Best Regards,
Elroy

[mtl777]

are you by any chance, running the vb6 ide elevated and the exe as a std user?
not that i have any idea if this would make a difference to crystal reports, as most here do not use CR, hard to find someone with experience to answer your problem

Thanks West for replying!

I'm not sure what you mean by "elevated" and "std user". Could you please explain?

[Elroy]

Elevated = "As an administrator"
Std User = "NOT as an administrator"



EDIT1: You could also set your compiled EXE to run elevated as well.

[georgekar]

@Elroy,
I think he has to check with sleep or doevents. He will preform a simple check.

[Elroy]

Hmmm, well, I suppose we should be clear then. Sleep and DoEvents do very different things. As Microsoft states, "Suspends the execution of the current thread until the time-out interval elapses." So, if Crystal Reports is running in the same thread (which I suspect it is), Sleep will only make things worse. If it's running in a different thread, it could possibly help a bit. However, if Crystal Reports is truly running in a different thread, it'd be best to just return control to Windows after a Crystal Reports "command" is issued, and then let the user wait until that "command" completes.

As opposed to Sleep, DoEvents basically operates on the current thread of the executing VB6 program. A very different scenario than Sleep.

To restate, if Crystal Reports is running in the same thread, then just issuing it a "command" (via some member [method or property]) should cause the thread to go into that Crystal Report member and not return until that "command" had completed. In other words, nothing for DoEvents to do (other than to possibly cause problems, possibly allowing the user to click the "print" button twice or three times etcetera before the first report even finishes, or possibly even starts). Except in rare occasions, DoEvents is almost always evil.

But mtl777 is certainly welcome to try. I'll be quite surprised if DoEvents makes any different.

I suppose I'll bow out of this thread now, again, not having any real experience with Crystal Reports.

mtl777, best of luck with your problem.

Best Regards,
Elroy

[mtl777]

Elevated = "As an administrator"
Std User = "NOT as an administrator"



EDIT1: You could also set your compiled EXE to run elevated as well.

The exe is in a network share. When I right-click > Properties, I see the Run this program as an administrator option grayed out.

I tried copying the exe to my local machine where I am logged in as administrator and ran it from there. Viola! It runs fast now! But I only tested three records as it was already late and I had to go. I'll do a more extensive test next week.

So it seems we're making progress! If running the exe as elevated is the solution to my problem, how do I set my compiled exe to run as elevated? Is this something I can do during compilation?

Thank you so much!

[westconn1]

it is bad practice to always run elevated, unless your program does tasks that required elevation
in a domain, users often do not have access to elevation
the new information you have provided now, may be more relevant
running from a network share

[Elroy]

Ahhh, I didn't see the "network share" before. I actually do have experience with this. My primary application almost always runs from a file server, although there is an option to have it run from the local (typically C) drive.

VB6 will often be making references to its EXE file. In other words, there will often be disk I/O between the EXE and the particular computer executing the program, pulling various things into memory, as needed. Therefore, if you have a slow network connection, this can definitely slow things down. I've had more than one client attempt to run my application over a WiFi network connection, and everything was painfully slow. It's those situations that encouraged me to give them a local C-drive alternative.

When you're running from the IDE, you're almost certainly running much more locally than when you're running an EXE from a networked drive. With this information, I'm thinking that's more your problem than anything to do with Crystal Reports.

Also, now that I know that, I doubt it has anything to do with running elevated (as administrator).

I have no idea what kinds of "assumptions" your EXE makes, and how much it might use App.Path, but you might try just running an EXE from the C-drive and see how that works.

Good Luck,
Elroy