>I realize that many have provided you with how to get your request done. But may I suggest a Linux box running samba. With the p2p installs I have done the actual workstation could never be used because it was to busy acting as a server. So if you can't use it as a workstation then why not turn it into a real server? Linux is free and Samba performs as well as many windows servers available today when comes to file sharing.

Can you offer any tips for configuring Samba on Linux servers to support VFP apps?

The reason I ask is that the only exposure I have with this is one client. They have 2 line-of-business apps:

- App 1 was originally FPDOS 2.5, recompiled to VFP5 with minimal changes to fix Y2K issues. This uses just free tables, which are on a Samba server. This app generally runs OK but needs periodic reindexing (a couple of times a month), otherwise users get invalid seek offset errors (corrupted indices)

- App 2 is native VFP5 using the Visual FoxExpress 5 framework and tables in a DBC. This was originally installed on the same Samba server as App 1, but got to the point where it would not run even a day without corrupt indices and duplicate primary key values being created. They had an old server that wasn't being used, and an old copy of Win NT 4 Server which they installed on it. This Win server just holds App 2's files. App 2 running against this box is 100% reliable, installed on the same network segment as the Samba server

As you probably know VFP is one of the sternest tests available for SMB and workalike file systems. I suspect that default Samba settings may not be optimally reliable for VFP and that some tweaking may be required. I'd be interested in hearing about any such tweaks.

***********
I've been supporting these apps at my client for over 10 years. One thing I've noticed on several occasions over that time span is what I call "file reversion", for want of a better term.

App 1 is structured to use a lot of individual .FXP, .SPX, .MPX, .FRX files rather than one or a few monolithic .EXEs. On the several occasions mentioned above I've gotten calls from the client saying "the app doesn't work" or "a report looks different from before". What I've found is that runtime files have been "reverted" back to old versions, that vary from 3 to 7 years old!

In most of the cases I've been able to rebuild the affected runtime modules by recompiling the source. However, in one case the source code was reverted; it was impossible to pinpoint when that happened, because the runtime module was one that gets used only once or twice per year, in September, so it could have been any time in the past year. The client checked all their available backups (that went back only to February) and the file was the reverted one on all of them. So, I had to rewrite all the changes to the source that had happened in the last X years. Luckily in that case there were only 2 enhancements and I remembered what they were.

But, I tell you, silent reversion of runtime and source files for LOB apps is no fun. This is definitely a Samba issue; if you've heard anything on how to address this I'd be all ears.