VFP 6 program slow preview / printing issue

[ducklord]

My office is still using an accounting software compiled with VFP 6 (vendor long gone).
Databases and software stored in Server with Windows Server 2016.
User with Windows 10 accessing the software is experiencing slow preview / printing issue, e.g. whenever I click the print button for printing invoice, it will takes 5 to 15 seconds to show the printer selection windows.
However, for user with Windows XP, the print / preview speed is fine (less than 2 seconds).
I have excluded the .exe from win defenders, but does not help the issue.
Thanks.

 

[GriffMG]

I would suspect this is a printer drivers problem - does the Windows 10 machine have a number of networked printers installed?

If so, it could be that the software is polling them before presenting the report.



Regards

Griff
Keep [Smile]ing

There are 10 kinds of people in the world, those who understand binary and those who don't.

I'm trying to cut down on the use of shrieks (exclamation marks), I'm told they are !good for you. ​

 

[ducklord]

Yes. I would try removing all of the printers and see if the issue persists

 

[Chris Miller]

As you say the step that already takes so long is getting to the "printer selection windows", well

a) is it really just a printer selection listing all available printers?
b) what do you mean with windows (plural)?


A FoxPro function to start a simple dialog for selecting one of all available printers is GETPRINTER(). But there's nothing more to it from the side of Foxpro, i.e. how long that takes to appear does not depend on FoxPro, but how long it takes Windows to have a list of all printers.

Another thing you can do to make your own printer selection is use APRINTERS(), there you have mainly two options of getting a basic information list or a verbose information list. That would perhaps allow to make it shorter and use the basic information list. But again, it's mainly Windows system providing the list.

And then a REPORT commandcan have a PRINTER PROMPT for the user to pick a printer for that report specifically.

So how does the printer selection look like?

Besides being XP style, the left window is what you'll get with PROMPT in the REPPORT FORM command, which also allows to set the range of pages you want printed, for example. And the second one is what you'll see when GETPRINTER() is used.

Since you're not the developer of this application the good news is in both cases and even when the dialog looks different and is something based on APRINTERS(), it must be fixable on the Windows system level outside of Foxpro or the application. The bad news is, that it's not straight forward to track what takes so long, since this is happening outside of the FoxPro process.

Chriss

 

[ducklord]

Thank you guys for your input. Surprisingly the printing speed became normal (takes less than 2 seconds to display the printer selection) before I removing any of the networked printer on this pc.

Anyway, the printer selection look like this:

I found that this "slow printing issue" never happen on my Server PC.

Let me share with you my office "PC setup":
- 1 Server PC (192.168.100.2): Dell T440 with Windows Server 2016 Essentials with Dell EMC Boot Optimized Server Storage-S1 (x 2 SSD Raid 1)
- 20 User PCs (192.168.100.3 - 192.168.100.22): Dell Optiplex Desktops with Windows 10 Pro (21H2), processors ranging from Intel i5 gen4 to gen8, all with SATA SSD or NVME SSD
- All the PCs are under 1.0Gbps Gigabit Ethernet network.
- All the VFP 6 software files (exes, databases, reports) are stored in the server a D drive directory which is shared to the network (e.g.: \\192.168.100.2\VFP\winacc.exe)
- None of the exe files were launched locally. The User PCs will launch the software from clicking the respective shortcut at their PCs (\\192.168.100.2\VFP\winacc.exe).
- When launching the software from the Server PC, I would still execute \\192.168.100.2\VFP\winacc.exe instead of D:\VFP\winacc.exe

Is there anything that can be done which should improve the software performance in a local network environment? I have researched online that antivirus should exclude the exe files. How about networking tweaking like disabling SMB2, Oplocks, Global Auto tuning, interrupt moderation etc?

 

[Chris Miller]

Your listing of CPUs, hard drives, network connection etc. are not essential to how long it takes to present that printer selection dialog.

I'm 999% sure this is coming from reports started with DO REPORT FORM... PRINTER PROMPT, so reports using the PROMPT clause.

And that dialog is a Windows dialog, and it's performance could marginally depend on network speed, it mainly will depend on how smart the server and network admins and DevOPs team of the company set up the printer system of windows including spoolers etc. Pardon me, if you're that role in our own company.

You can do pretty much nothing from VFP itself to make that faster or even vice versa slower. You just call out to Windows to present that system dialog and that's your part of the story. What you could do is do without, but the alternative then is no printer choice or roll your own printer choice with meta data about available local printers, but that's a two edged sword, as while that could be very much faster it's something to maintain to know and keep up the meta data about local and nearby network printers.

VFP has, as already mentioned, APRINTERS. There also is ANETWORKRESOURCES. I won't go into redoing all the other features of the dialog just to prevent using it. This really and simply has to be addressed by someone else, or in the scenario you're the company's IT department, you in your other role as network and printer admin.

using ANETWORKRESOUCES can give you a hint on how fast or slow it is to investigate the network for available network resources. That mechanism does not only depend on the network cards and their bandwidths, it depends much more on Windows management and how it handles knowing those resources. In short I'd go into WMI instead of trying this with VFPs marginal functionalities going in that direction.

Chriss

 

[Chris Miller]

BOFH anecdote #451233 of #**********:

When server connections often didn't work, some colleagues of their it department often told me there was a loopback route somewhere in their routers that caused the time to live (TTL) to go to 0 before a connection request could even arrive at a server. And it wasn't only one case, it happened very frequently. And still they always came to me first.

Edit 1: Well, in some instances they came to me and said the server guys didn't find any issues. Well, of course not, the problem is in the network between my responsibility of the software and the responsibility of the DBAs.

Edit 2: The successor to a retired colleague once even installed new cabling in many offices. He didn't learn anything from the fact that the software connected perfectly well on one day and then not on others and again on the next day went back to good with no version change.

Same with anecdote #4u534xy:
They (another company) found out (for themselves) clearing a browser cache helped and informed me I could stop looking for a problem in m code. Next day they came up with the same problem, I asked them to clear the browser cache, and that worked. I always think communicating this to me is fine, but why don't they communicate these things to who should know it in the first place?

Chriss