Visual FoxPro and Windows 7 64 bit

Fifteen and a half years ago I became a professional computer programmer.

That is a statement that many who know me would dispute.

Some would say that I actually became an IT professional, who later gained the opportunity to write computer programmes; whilst others might say that I never took the opportunity to become a proper programmer – relying instead on a form of software development tool that is more akin to Lego than the cold-iron forge of “proper” programming languages.

Regardless of popular opinion, fifteen and a half years ago my life was enriched by the beauteous legacy that is Visual FoxPro.

I intended this post to be an informative guide to aid fellow Foxers in moving their soon-to-be-legacy (or should that be should-soon-be-legacy) systems to the 64 bit version of Windows 7.  However I seem to have tapped a hitherto unknown passion for the “beautiful piece of foul” that FoxPro is.

At the risk of breaking the narrative, the secret to successfully implementing your Visual FoxPro application on Windows 7 – 64 bit or otherwise – is as follows:

  1. If you’re using ODBC on a 64 bit instance of Windows 7 (or, heaven forbid, Vista) remember that the beautiful Fox cannot use 64 bit drivers.
    1. It will, however, use 32 bit drivers.
    2. Simply configure your drivers in the 32 bit version of ODBC management that can be found in c:\windows\SYSWOW64 – ODBCAD.EXE I think.
    3. If you encounter poor performance then make the following checks:
      1. Exclude your VFP application’s working folder from your Anti-Virus package’s real time protection… obviously you need to weigh the performance benefits against any potential security risk – if you think your Fox application is at risk that is.
      2. Disable file caching on the local hard drive.

i.      You can do this in Device Manager.

  1. Remove redundant entries from your PATH statement, specifically any drive mappings that may no longer exist.
  2. Finally, and most productive for me, disable Interrupt Moderation in the advanced settings of your network card.

i.      You can get to this setting by right clicking your network connection, going to Properties or Status, then Properties and clicking “Configure” next to the network card… in the “advanced“ tab you may have an option for Interrupt Moderation – equally you may not – if you do, disabling it might make your networked VFP application run a hell of a lot faster… it has for me, every time.

Now the advice is out of the way, let me get back to technostalgia…

Visual FoxPro is – nay was – the single most, greatest development tool once available through Microsoft.  Sadly, the vulpine professional has all but 35 months before Microsoft cut off support and leaves us to the limitations of the development tools that follow in its paw prints.

I’m being overly harsh.  The tools that follow are just as useful – I can code just as comfortably in Visual Basic 2008 nowadays – but I have a soft spot for FoxPro.

I’ve used the beast in anger for something under a half of my life and I have no doubt that I will use it for many years after Microsoft pull the plug and leave her to die.

Back in the early days I was taught to use Visual FoxPro version 3.0; an object oriented database development tool that was far more versatile than its peers.  I was also just coming to terms with Windows 95 – remember that?

What a leap, from poking around with Windows 3.11 and programming in basic on a BBC Micro to fumbling my way through the revolutionary Windows 95 interface and learning to build applications in Visual FoxPro 3!

Year on year, Visual FoxPro came on leaps and bounds.  From 3 to 5, then 6, 7, 8 and 9, the Fox continued to get better and better.

After version 6, Microsoft dropped it from their Visual Studio package; choosing instead to push the vastly inferior Jet database engine (Access *spit*) and my preferred database environment, SQL Server.

In 2006 I was given the opportunity to drive the growth of a local telecommunications service provider by building a CRM/ERP platform to replace their failing existing platform.

With the caveat that Visual Foxpro was due to lose support 8 years on, I received permission to write the platform using Fox.  I used SQL Server 2005 as a back end and have since upsized the database to SQL Server 2008.

Throughout the development process I made sure that Visual FoxPro could be left expendable by ensuring that the majority of the business processes were handled at the back end.  Fox really was the Client to SQL’s Server.

Now, five and a half years on, the stakes have been well and truly upped.

I have – sorry, my mistake – my team have written Client applications in Visual Basic (versions from 6.0 to 2008), PHP and beyond but the core system is still based in good old robust Fox.

Robust that is, until Windows 7 64 bit came along.

For the past month or so, some users have complained about poor performance.

Whenever we looked at the back end server performance, everything was running as optimally as it could be – but the end user still suffered from slow screen refreshes and a generally clunky user experience.

Last autumn we took on 5 new members of staff, supplying them with shiny new Dell machines, all running Windows 7 Professional 64bit; these were the effected parties .

Only the VFP application seemed to be effected.  It ran fine initially but at some point since Autumn 2011 something must have changed on those PCs to slow them down. The app hasn’t had any major revisions since then and the only other thing that has changed recently is that we moved premises over Christmas, all the PCs now connect to a gigabit network with gigabit cards (in PCs and servers) and gigabit switches. They even have brand new cables (It’s one of the services my company offers, we know what we’re doing when it comes to this kind of setup).

I tried everything I could think of:

I tried reinstalling the runtime files.

I tried disabling Anti-Virus.

I switched of file caching on the local drives

I checked my environment settings to see if I wasn’t asking Fox to do something out of the ordinary on the effected PC’s.

I even went so far as to implement nth degree debug solutions to trace what was happening on the effected PCs as opposed to unaffected PCs.

I trawled the internet, starting with my favourite source for Visual FoxPro support, The Universal Thread; then I came across this post on stackoverflow.com.

The solution there in black and white worked for every single PC.

I mention it above but the solution to my problem was simply this: Disable the Interrupt Moderation setting in the Network card’s advanced configuration.

Simples.

All that polava to get my app working on Windows 7 – here’s to hoping Windows 8 is delayed…

This link on stackoverflow.com suggests that disabling the network card driver’s Interrupt Moderation setting can sometimes speed up a networked VFP application that is running on Windows 7

10 thoughts on “Visual FoxPro and Windows 7 64 bit

  1. Thanks Incurus!

    It took a few hours to get to the point of finding and using that final tip, if it helps other people out then it makes the efforts even more worthwhile.

  2. “I can code jus as comfortably in Visual Basic 2008 nowadays – but I have a soft spot for FoxPro.” Ignoring the typo….. really you’re that good or is it because you use the same seat?

  3. Any idea where I can get a copy of the VFPODBC driver? Microsoft no longer offers it and I’m trying to get ODBC connections working on an old FoxPro database (with VFP8 installed) using Win7Pro-64bit (via the 32-bit DSN dialog).

  4. BRILLIANT! Thank you very much for this link. The driver was indeed there and it was a snap to get the thing installed and running.

  5. I found this information so useful, I thought I’d share this tidbit with you in return: Dell Servers that ship with the SAS 6/iR RAID controller have Caching enabled by default. You might not think this an issue until you realize the 6/iR doesn’t support Caching! For our beloved Fox, this means corrupted indexes and poor performance back and forth to the server in general. (Combine this issue with that of the very similar and well documented SMB2 problem and you have a tough problem to diagnose) Caching can be disabled in real time via any of Dell’s server management products and corrects the problem immediately. Thanks for such a great article!

Leave a comment