>>Yes, definitely with NetBIOS-style UNCs e.g. \\NetBIOSServerName\ShareName\FolderPath\FileName .
>>
>>However, the OP is seeing issues with internet/FQDN-style UNCs e.g. \\MyServer.MyDomain.com\ShareName\FolderPath\FileName .
>
>Sure it works - I use IP Addresses locally for the server name all the time to directly connect to local machines and that is in effect the same as domain names. I've also connected to my live servers this way using domain names and that works the same, but it is slow, especially the initial connection as the NetBios protocol is verbose for connecting and navigating the security and finding the share to connect to.
>
>It works as long as you have a valid domain name or IP address **and** you have a way to actually reach the server using NETBIOS ports **and** you have the right Windows ACL permissions on the server. By default Windows has that firewalled off and you need to enable the networking options for public/private access to allow non-NETBIOS access to the server. IP Addresses and domain names work, but resolving the host may be slow via the Windows NETBIOS apis. Even though it works, I wouldn't recommend it for that reason alone - connections to open Internet Connections can take many seconds even if the server and DNS is otherwise fast.
>
>At minimum if you go that route - I'd recommend mapping a drive rather than using UNC paths as UNC has to resolve the path while a mapped drive doesn't.
>
>I've done this in the past with my live server connecting to Fox database, but it's very slow. Works in a pinch, but wouldn't recommend it for a production application.

I've been using mapped drives, NetBIOS-style UNC addresses and IPv4-style addresses for many years and know they can usually be made to work. An IPv4 address and an FQDN are only the same if DNS is available to resolve the name *and* VFP tries to resolve it in the first place. I didn't know VFP does try to resolve FQDNs, that's good to know.