I'm having a problem with vfp9 on Windows 7 64-bit. I've found that create sql view is taking 5-6 seconds. These happen instantaneous in XP. When my app starts up, I'm doing a few of these, so in Win 7, my app is taking 30+ seconds longer to start up than in XP. My views look like this:
create sql view MyView remote connection MyConn as select * from MyTable
I've also found that calling dbsetprop is adding another 1-2 seconds in Win 7. Again its instantaneous in XP.
dbsetprop('MyView.MyPk', 'Field', 'KeyField', .T.)
dbsetprop('MyView.MyPk', 'Field', 'Updatable', .T.)
Once created, the views work as they should. No slowness on with platform.
Does anyone have any ideas about what I could try or any info on what is/could be causing this?
Thank you in advance.
I don't know why as I haven't worked with Windows 7 yet with VFP... However, what I would check within VFP and try changing some settings to see if it helps.
From the VFP/IDE menu, go to Tools, then Options. On the multi-tab form, click on the "Remote Data" tab.
I don't know if/what its trying to do, but maybe for testing, make sure the "Records to fetch at a time" is NOT set to "All" (checkbox).
I would also look into SQLSETPROP() function to see if any of those settings might help.
I can't reproduce this on Windows 7 64 bit, either with VFP9 RTM or VFP9 SP2. I don't have a database of any size to work with but on the sample database Northwind the commands you list seem to work instantaneously.
A couple of questions:
Is this reproducible on any machine running Windows 7?
Where is your database? Is it on the local machine, a local network, or the internet?
There seems to be more scope for speed problems with Windows 7 and Visual FoxPro (and similar) applications, and I think this is down to the different network stack in Windows 7, immature network card drivers, an increased susceptibility to cabling and network switch problems, or any combination of these.
Ensure that all your Windows 7 boxes are on SP1 (and any Server 2008 boxes with shared DBF files also), as this fixes a file corruption issue that affected Visual FoxPro indexes.
Ensure that your network card drivers are 100% up to date. This can make a big difference.
One thing that I have seen which can give a massive improvement to the speed of networked Visual FoxPro applications is the network card driver Interrupt Moderation setting. This is present on Intel, Broadcom and many other NICs, although with possibly slightly different names.
I have personally seen situations where disabling this has changed a networked VFP application from taking 30 seconds to start to about 6 seconds.
Found the solution.
Write caching was being disabled on the drive by the raid controller software included with the machine.
Write caching was enabled under Device Manager > Disk Drive > Properties > Polices. However the software was overriding this setting.
It can be reproduced without the raid software by unchecking it in Windows 7 Polices.
Related
I have some VB6 applications which have run well under every version of windows since XP. Now we are going over to Windows 10 x64 we are finding our our GUI application is very slow especially in SQL operations etc. We run all applications elevated and played around with various options in the compatibility tab but nothing stopped it from being laggy.
Recently i have found a huge improvement if i run the compatibility troubleshooter. the first time we test it fails because we then have to retry with the admin rights but then it seems quite good.
What i dont understand is what the troubleshooter is doing differently to manually selecting options and also even though i then tell it to save the settings, the next time the application runs its laggy again and we run the troubleshooter. I've done a little research and can confirm the applications are all run from the local hard drive. We also keep the database on the local drive.
Just in case it helps, Running different builds of Win10 from Anniversary to a clean install today of Fall Creator. The Visual Studio IDE is installed under the Program Files directory (not program files x86) and i deselected the ADO, RDS ODBC providers as suggested somewhere on the internet (there are ADODB calls could this have anything to do with it). The IDE runs also with elevated permissions.
There are essentially 3 applications with 2 running in the background. All reference a couple of DLL files from a 3rd party and run several SQL calls to a local database. We have noticed if the database is being accessed elsewhere (even through Access so not repetitively) this also slows down the GUI. This system need to perform realtime tasks and so this laggyness is affecting the operation.
Thanks in advance for any suggestions
The correct, and fastest, latest software to run a VB6 program is only found in the "Windows 7, (SP3)" modes, with elevated (Admin) permissions. Since that version, there have been many safety features added to windows, which have to be "emulated", in order for VB6 programs to operate within certain safe limits. The cost was speed, nearly half the speed, which is measurable with most time-demo codes.
Setting compatibility mode to "Windows 7, (sp3)", and elevating your program to (admin), will return your program back to normal speed. Actually, it will be faster than it was on that version of windows, but only in some areas.
This should be done manually, or at the point of install, of your program. You have to add registry keys, based on where the program is installed and how it is named or identified. Prompting the user so they can OKAY the elevated (admin) access for your program.
Even though it's still working, it's really not optimized for new operating systems - of course it's just Windows. There were a number of programs that used to work on Windows XP and today do not work at all.
As the language son wanted with the interpreter rather than compiling it - of course there are other languages as if they had undergone many optimizations (eg python). Which greatly reduces the software.
I ran into the same issue and resolved it by Compatability options as below:
Right-click on "C:\Program Files (x86)\Microsoft Visual Studio\VB98\VB6.EXE" and choose the properties option from the popup menu
Select the Compatability tap from the properties windows
Under Compatibility mode, Select "Run this program in Compatability mode for"
Choose "Windows-XP (Service Pack 2)"
Click OK and execute VB6
My hard drive is at 100% in Task Manager.
I disabled Windows Search and Superfetch and hard drive is still at 100%.
I am using Windows 10.
Any suggestions would be helpful.
Update: Task Manager won't show what process is clogging up hard drive at 100%.
Task Manager won't show any processes that use up a lot of percentage of hard drive.
I suggest you see the processes tab and see if any process that might be using maximum read/writes in your hard drive.
Disable Indexing service that sometimes use more resources. Disable any startup process that might be using your system resources.
Windows + R -> Run Menu -> Type: msconfig and see any startup process that you can disable. Disable any program that seems suspicious.
You can try some other repair methods like:
Perform a diskcheck
Reset Virtual Memory
Disable Antivirus Software temporarily
Change the settings in Google & Skype
Fix your StorAHCI.sys driver
Update your device drivers
Win10 100% disk usage
I had the same issue on my WINDOWS 10 system and I tried a lot of things like turning off the search indexing feature of windows but nothing worked using all that. Here is what worked for me. I opened the task manager and found that there was a task with Microsoft Compatibility Telemetry (CompatTelRunner.exe). It is a Windows process that is designed to collect and send usage and performance data to Microsoft. The executable file collects and regularly sends usage and performance information to Microsoft in order to analyze the user experience and improve it. The described file also helps Microsoft to identify compatibility issues and ensure compatibility when installing the latest Windows OS version. However, Microsoft Compatibility Telemetry eats CPU by scanning computer files and check their compatibility with Windows 10 in case an update is initiated.
I simply clicked on End Task for Microsoft Compatibility Telemetry and my disk usage went from 98% to 15% within few seconds. I hope it helps others experiencing the same issue as well.
I had the same issue with windows 10 on Laptop.
I set the windows update service from automatic to manual.
Now i am always under 5%.
Click on administrative tools in control panel
Then click on Services
set windows update to manual.
Had the same problem for months. Desactivated SrTasks.exe and it started working.
However this task is clearly something important, so I think it's not recommanded to stop it.
We have multiple applications developed in Visual Foxpro 8.0 running in a data center on Windows 2008 R2 on VMware. We also have a Citrix farm on the same network where users run yet another VFP 8.0 application in Citrix sessions. All applications share the same set of data tables located on a file server (also Windows 2008 R2 VM). Virtual hosts are connected by 10Gb LAN (managed switch).
Since mid-July we started seeing random 1104 "Error reading file..." errors on multiple different applications on multiple servers. All of them reference different files on the file server.
The problem started mid-July and it frequency gradually increased. Earlier it was most frequent in the afternoons by 3 pm, now it happens from early morning till late afternoon. It affects EDI servers (these run batch jobs in unattended mode) and Citrix servers and a variety of applications. It occurs when a VFP application (any of them) tries to open a database container file or individual tables most often with USE command but some times executing a SQL Select statement, or when loading a VFP form that opens tables in DataEnvironment
We caught a moment when the same exact error happened on two different servers running different applications at the same exact moment (up to a second). We also saw two different applications running on the same computer erroring out at the same moment.
We replaced the file server with a new virtual machine with no relief (we since changed it back to the old file server ).
We disabled the antivirus.
We updated VMware on all hosts to the latest version.
Sysinternals Process Monitor displays "INVALID_NETWORK_RESPONSE" event when the error occurs.
We captured traffic on both the server side and client side when the error occurred and had it analyzed by a network analysis specialist. He observed a peculiar pattern, where client OS starts retrieving the file in question from the file server AFTER VFP application had thrown an error. It seems that VFP application requests a file from OS, then it either gets an abnormal response or just times out and only after that the OS sends packets requesting the file. Again, this happens sporadically.
OpLocks and SMB2 have been disabled on all computers both on the server and client side of the equation for many years and everything was running smoothly until now...
Any advice would be greatly appreciated.
My first piece of advice would be to re-enable OpLocks and SMB2. There is no reason to mess with either of those items as things stand today and you are losing a huge amount of performance running at SMB1 level.
In my experience these issues have almost always been caused by one of the following.
Antivirus/antimalware software.
Replication or online backup software like MozyPro.
The Windows Search indexing service.
You should consider installing the Windows 7 / Server 2008 R2 Enterprise Hotfix Rollup if you haven't already.
That problem mostly related by SMB2!
Some Antivirus Software!
Windows updates! If you use VFP apps by DBF/DBC file. Do not update your system/OS. That is my personal suggestion. Windows Server 2012+ or Windows 10+ prorbably would big problems at near future.
And the point high probably is:
What is your I/O request per secs? if your IO request bigger than 1000~2000 per secs for a dbf file that is a bottle neck; and your storage device is HDD -> you need to switch/update your HDD to SSD. I suggest m.2 pro series SSD.
The LAN which has about a half dozen windows xp professional pcs and one windows 7 professional pc.
A jet/access '97 database file is acting as the database.
The method of acccess is via dao (DAO350.dll) and the front end app is written in vb6.
When an instance is created it immediately opens a global database object which it keeps open for the duration of its lifetime.
The windows 7 machine was acting as the fileserver for the last few months without any glitches.
Within the last week what's happened is that instances of the app will work for a while (say 30 mins) on the xp machines and then will fail on database operations, reporting connection errors (eg disk or network error or unable to find such and such a table.
Instances on the windows 7 machine work normally.
Moving the database file to one of the xp machines has the effect that the app works fine on ALL the xp machines but the error occurs on the windows 7 machine instead.
Just before the problem became apparent a newer version of the app was installed.
Uninstalling and installing the previous version did not solve the problem.
No other network changes that I know of were made although I am not entirely sure about this as the hardware guy did apparently visit about the same time the problems arose, perhaps even to do something concerning online backing up of data. (There is data storage on more than one computer) Apparently he did not go near the win 7 machine.
Finally I know not very much about networks so please forgive me if the information I provide here is superfluous or deficient.
I have tried turning off antivirus on the win 7 machine, restarting etc but nothing seems to work.
It is planned to move our database from jet to sql server express in the future.
I need some suggestions as to the possible causes of this so that I can investigate it further. Any suggestions would be gretly appreciated
UPDATE 08/02/2011
The issue has been resolved by the hardware guy who visited the client today. The problem was that on this particular LAN the IP addresses were allocated dynamically except for the Win 7 machine which had a static IP address.
The static address happened to lie within the range from which the dynamic addresses were being selected. This wasn't a problem until last week when a dynamic address was generated that matched the static one and gave rise to the problems I described above.
Thanks to everyone for their input and thanks for not closing the question.
Having smart knowledgeable people to call on is a great help when you're under pressure from an unhappy customer and the gaps in your own knowledge mean that you can't confidently state that your software is definitely not to blame.
I'd try:
Validate that same DAO and ODBC-drivers is used on both xp- and vista machines.
Is LAN single broadcast domain? If not, rewire. (If routers required make
sure WINS is working)
Upgrade to ms-sql. It could be just a day of well worth work, ;-)
regards,
//t
Let's say you have a slow laptop which can't handle Visual Studio but a blazingly fast desktop that can. Let's also say that you want to develop in several rooms in your house. Are there any drawbacks to having Visual Studio running on the desktop and simply using the laptop as a way to access it remotely? I'd guess that the only thing that you would be concerned about would be the network latency, but if the two computers are on the same network that should be minimal.
Do it.
Since you are running Visual Studio in your own local network, the main drawbacks (security and latency) are not there. In addition, you get the speed of your desktop and the mobility of your laptop.
I do this a lot even over broadband, I've never found speed to be a problem.
This is my standard working practice at work. There are times when you have issues, such as opening TFS document attachments can fail, but overall the experience is fine.
It is also an added bonus that you can leave it running continually (i.e. overnight / weekends) and you can kick off a build before you leave for the evening and come back to a packaged installer (or an error :) ).
I'm looking forward to (in a year or two) be able to do this over Hyper-V - then the application will run as though it IS on my laptop, with no remote desktop required.
No big drawbacks. I've been running VS 2008 remotely on a server 400 miles away, using GNU/Linux and rdesktop on my laptop and the server (of course) running Windows. The only problems I encounter are that it is a mess to move files between the two - but if you have the desktop near and can install anything you like (ftp programs for example), I can't see any drawbacks.
In a corp work environment where I've tried this I never felt particularly joyful. Tried using MSTSC and VNC.
Having a desktop with multiple monitors and trying to view that through a smaller laptop display is typically quite painful, never enough space.
Even when it was PC's on the same switch there always seemed to be some delay in the mouse moving or typing, I'm sure you could adjust, I just found it a bit annoying too.
We haven't tried serving up DevStudio from a CITRIX server yet, that might be worth a go.
I work a lot with Visual Studio over broadband, which is ok.
If you are running linux on your laptop, rdesktop is your friend. There are many options to gain more speed, like using 8-bit color instead of 16 or more. I don't know if mstsc offers such options. Visual Studio 2008 has got many options concerning speed which can be enabled if the connection is too slow: disable fancy menus etc.
greetings
I think that having the dual (or more) monitor set-up does beat the ease of mobility when using a laptop connecting to a remote desktop. I work at home at least two days in a working week using my laptop (which is a 17", 1900x1200 screen, basically what they call a "desktop replacement"), connected to VS and TFS using VPN and I find that experience less than the situation at work where I have the 17" laptop screen AND a 24" TFT (also 1900x1200).
I also have experienced that running VS (or SQL Server Management Studio for example) over an RDP session is just not like the real thing. It does get the job done, however the "feel" isn't just the same.