First off as Tushar advised in a previous thread the UNC should work for you on both server and workstations. I generally use the UNC approach for a variety of reasons.... please read on below.1. I do not have to contend with any drive mappings at all on any workstations or server.2. If I am running under active directory I do not have to fiddle with Netlogin user group scripting to map the required drives.3. I can setup the network share as a hidden share so the share cannot be seen across the network or navigated to by the users. You do this by creating the network share name with a $ sign after the name. You do need to assign the user/groups read-write access to the server folder where the data resides for VFP native database backends. So you should have the required user/groups in the Security permissions at an NTFS level and in the Sharing tab - Permissions button have the required user/groups assigned as Change and Read permissions.4. With a mapped drive the LAN users could navigate to your application and data folders and accidently delete, rename or drag and drop the folder or folders by accident, killing anyone on the LAN running you app until you find out what happened and fix it... so why not just side-step this problem completely and use a hidden network share and a UNC to point to the server share location folder or folders.

So above you can see the kind of lock down security and problems you can avoid with just a little up front planning!

A few more options for your consideration. . .

In your Main.prg startup program you could call a UDF to test for the UNC path being available prior to attempting to set the default to command.

A very simply UDF like below in your project saved as a .prg would do this for you... see below:

So you can see there are many ways to do what you want to do and all are very easy to impliment in a VFP program!

The ping command test if the server is on the network, the function shown above and the ON ERROR trap tests for the existance of your UNC path to the server.

If you really wanted to take this entire process to another level "in cases where network infastructure is not the best", then in all your VFP cursors use Buffering Mode-5. Then you can call something like the above CheckUNC.prg function to re-test the network connectivity to your targeted UNC prior to issuing any TABLEUPDATE() command. If the UDF function returns .F. you can issue the TABLEREVERT() VFP call and provide a MessageBox to your users that server connectivity has been lost and gracefully close down your VFP application until the problem has been resolved.

Don't forget that a FLUSH command after a TABLEUPDATE() as this can reduce VFP table corruption issues across a LAN.