Friday, February 27, 2009

Where did my FoxPro Application Go?

I have been meaning to blog about this for almost a year but kept pushing it to the back burner. A client of mine had an intermittent problem for quite some time. The problem occurred when the users would have the application running and switch to another window like FireFox or Outlook or even another instance of the application. When they would come back to the original application window, it would be gone. No error, just gone.

Once of the things that I did shortly after I started on this gig was to move the runtime files from the server to the local workstation. The system was already launched from a .BAT file that copied a bunch of junk to the local machine so why not copy something useful? As you might expect, in a company with close to 300 users at any time, this move reduced the network traffic quite a bit.

Once the runtime files were moved, we started getting intermittent (but frequent) "Invalid Seek Offset" errors. The network guys insisted that this was an application problem and I insisted that it was a hardware problem. After much Google searching, they network team finally conceded that this was indeed a network issue. It was several network issues actually, NIC cards, bad cables, overloaded hubs... So, my move actually helped make the network stronger.

Once the "Invalid Seek Offset" errors started, the disappearing application windows went away totally. Interesting... when a network connection (or drive mapping) is lost and VFP has to make a call to the runtime files located on a network share, it just shuts down because it can't find the necessary files. It shuts down gracefully with no error message. Sure, data in memory is not saved but no data becomes corrupt either.

On the other hand, Invalid Seek Offset errors are really bad. FoxPro's error handling does not trap these errors and once you get one, you are not getting out of it without an End Task which can corrupt data. So, which do you choose... High network traffic and low risk for data corruption or low network traffic and high risk for data corruption? Luckily this company chose to use the errors (as horrible as they were for a short time) to correct the network problems and make the infrastructure more sound over all. Now the system runs efficiently with next to no network related errors. I would never have expected FoxPro to just shut down when it couldn't find the needed internals.

Have a great weekend!