<< If I have a multiuser workstation application, with native VFP data on an NT server. I access the files using drive mapping. This has proven to be very distructive to my files and database due to lock ups. >>

The problem you seem to be having, like the other poster stated, was more of
Network troubles, and not being able to maintain a clean connection with the files on the server.
I started having those kinds of troubles with actual network collisions, before I had my company invest in some good equipment, changd the network to a 100 base t switched network, from a hubs all over the office. Made a big difference. Also with a switched netowork, you can see from the network, where there are collisions and bad data, to spot when one of the workstations network cards are going out etc.


Any ideas or suggestions is appreciated

But the reason I answered this post, is the other part to of your comment, about changing your app to client server.

And in my opinion, its worth it. Very much worth at least starting the process. sql server (any sql server,) is for the most part faster, and more stable

considering that you have the knowldge of working with a Great Front end tool like VFP, going that extra to learn, and setup, what the Big Guys DBA's at oracle, already know, at least for me has been the most fun since I moved away from dos fox, to VFP.

Dont expect to get-it overnight, or be able to rewrite your code in a weekend, its a bit more tricky than that. But I made the decision a few months ago, not to use the DBF dbc file structor a few months ago, for anything. and I am never looking back.

The internet has changed my customers opinion so much, that all they want is more more more. and relying on a network based shared drive solution... Well, is a band aid...the client server, and distributed application market with distributed database shema (sql based) or xml based, is what the future will require. --