>>>>>Hi,
>>>>>
>>>>>I am looking through an error log of one of the customers. They didn't report a problem. But I see it in the log file.
>>>>>But something is strange.
>>>>>The error says:
>>>>>

>>>>>error reading file \\servername.organization.healthcare\appfolder\libs\dl_error.vcx
>>>>>

>>>>>dl_error is a library in my application that handles the errors.
>>>>>appfolder is the share where the program resides. This is correct
>>>>>But what is strange is that nowhere in the configuration files there is the name:
>>>>>

>>>>>\\servername.organization.healthcare
>>>>>

>>>>>The configuration has a different main application share name:
>>>>>

>>>>>\\servername\appfolder\
>>>>>

>>>>>The server name is also not matching the name in the error.
>>>>>
>>>>>My question is, why does the error look for the error library (vcx) in some "non-existing" folder?
>>>>>
>>>>>TIA
>>>>
>>>>I received a reply from the customer IT explaining the situation. They have a somewhat complicated situation. The same server (VM) and the application share are accessed by users from one entity (hospital) and another entity (government). So, he said that when the connection is coming from the hospital the DNS points (if this is the correct term) to the \\servername\appfolder\. And when the users are the government, the DNS points to the \\servername.organization.healthcare, This is how I understand his message.
>>>>My questions to the gurus here are:
>>>>1. Can the same VM and the same share have two entries in the DNS? That is, accessed by two different ways?
>>>>2. Since mostly I see the problem with the \\servername.organization.healthcare (and not with \\servername\appfolder\), can I point to the IT guy that they have a problem with the DNS?
>>>
>>>Martina explained why VFP is throwing the error. In VFP UNC-style file names only support NetBIOS host (computer) names, not internet FQDNs.
>>>
>>>If two different organizations are accessing the same server\share from two different sites/environments, chances are computers in those two different environments are served by different DNS servers. Those may certainly return different results for the same lookup. However, I'm not sure how DNS would apply in the situation as you describe it. A regular DNS lookup accepts a hostname (fully qualified or not) as a parameter, and it returns an IP address. Such a lookup will never return either "\\servername.organization.healthcare" or "\\servername", those are not IP addresses.
>>>
>>>The following is a lot of speculation, but what *might* be happening is an issue with the folder from which your app is started. Some apps are designed to check the folder from which the EXE is running, and then look for app components on paths relative to the the EXE folder e.g. appfolder\libs. This may or may not use the VFP SET PATH command. Even if this is not done explicitly, then VFP might search relative paths like that if components that were built into the EXE were in those relative paths in the original project.
>>>
>>>Consider the "Shortcut" tab of the properties of a desktop shortcut to an app. There is a "Start in:" field. This does not have to start with a drive letter such as C:, it can be a UNC path instead. Since the dawn of time Windows UNC has accepted NetBIOS-style share names such as "\\servername\appfolder". More recently (not sure when) Windows started supporting internet-style fully qualified server\share names such as "\\servername.organization.healthcare\appfolder". Although Windows supports the latter style of UNC naming, so Windows can find your app and start it, VFP does not. So if your VFP app explicitly or implicitly makes use of that in its "Start in:" path, it will cause the failure you're seeing.
>>>
>>>If users at the two different sites are using desktop shortcuts to start your app, you could inspect that "Start in:" field in the shortcut properties. You might find:
>>>
>>>- the ones that are working ("Site 1") have "\\servername\appfolder\"
>>>- the ones that are not working ("Site 2") have "\\servername.organization.healthcare\appfolder"
>>>
>>>As a test (and workaround if successful) you could get a user at Site 2 to map a drive letter to the share, either using File Explorer or directly in a CMD window using:

>>>* Map the Z: drive letter to the share:
>>>NET USE Z: \\servername.organization.healthcare\appfolder
>>>* To get Windows to remember a mapped drive across sign outs/restarts, add the /persistent:y flag at the end e.g.:
>>>NET USE Z: \\servername.organization.healthcare\appfolder /persistent:y
>>>

>>>Then, the Site 2 user can change their "Start in:" field to "Z:\" and test with that.
>>>
>>>A sysadmin could optionally map such a drive letter for uses who require it using Group Policy, so users don't have to worry about setting up and maintaining that drive mapping on their computers.
>>>
>>>If desktop shortcuts or similar are not being used, the same effect might still happen if a user browses directly to your app in File Explorer i.e. Network --> Server --> Share, then double-clicks on your app's EXE. This would start your app with a UNC "Start in:" folder.
>>>
>>>Once a drive such as Z: is mapped, the user can browse to your app in File Explorer, drilling down from Z: drive instead of Network. That would be another way to test if a mapped drive addresses the issue, without using shortcuts or similar.
>>>
>>>There's a rabbit hole of related discussion at https://serverfault.com/questions/908527/windows-file-share-through-fqdn .
>>
>>Al,
>>First, thank you very much for the detailed reply.
>>
>>The key to the problem is explained in your sentence:
>>>>Martina explained why VFP is throwing the error. In VFP UNC-style file names only support NetBIOS host
>>>> (computer) names, not internet FQDNs.
>>Honestly, I didn't understood that this is what she was saying. I understood it could be a problem but not the "NetBIOS" vs "FQDN" concepts.
>>
>>Let me describe, briefly how my app works:
>>The application location in the desktop shortcut is specified in an UNC. For example:
>>\\servername\sharename\appname.exe
>>The Start In does not have to be specified. The application, on Start (within VFP code) determines the "home" location and uses it throughout the program.
>>
>>What I need to find out is how this customer specifies the application in the desktop shortcut (for those users that use the FQDN). From your description, I understand this could be the problem (sorry if I misunderstand). That is, if the shortcut specifies the application as:
>>\\servername.organization.healthcare\sharename\appname.exe
>>it would cause the problem.
>>
>>And if I understand you correctly (again, sorry if I don't), one solution to this would be if they MAP the share instead of using the FQDN. Correct?
>>
>>Meanwhile, I will ask the system engineer to let me know the exact values specified in the desktop shortcuts of user who use FQDN.
>>
>>UPDATE: I wonder what would the following code (I use to get the home share/folder) would return when the user starts the app from FQDN?:
>>

>>pcExePath = addbs(justpath(sys(16,0)))
>>

>
>Yes, you've understood my speculation, the question is whether it's causing your issue. To recap, VFP supports these folder/file naming syntaxes:
>
>1. DriveLetter\FolderPath\FileName . This can be:
>- A path on a local drive: LocalDrive\FolderPath\FileName e.g. C:\SomePath\MyApp.exe
>- A path on a network drive: NetworkDrive\FolderPath\FileName e.g. Z:\SomePath\MyApp.exe
>
>Mapping a network drive letter with NET USE is a handy way to abstract away a lot of behind-the-scenes networking complexity. In your case it lets you convert a syntax that VFP does not support (\\FQDNServerName\ShareName\FolderPath\FileName) into a supported network drive syntax.
>
>2. \\NetBIOSServerName\ShareName\FolderPath\FileName e.g. \\servername\sharename\appname.exe . This is UNC syntax with a NetBIOS server name.
>
>The way this works is somewhat similar to DNS. On any Windows network which supports NetBIOS there is one computer which has been "elected" by all the computers on the network to be the "Master Browser". It enumerates the computers on the network and the file and printer shares they expose. On most Windows networks this will end up being either a domain controller (DC) or a server running a server OS that is not a DC or backup DC.
>
>Since Windows Vista/Server 2008 some "new" security concepts apply. A given computer and its resources can be on a "trusted" network (usually private, either "Work" or "Home") and it can optionally be "discoverable". "Public" networks such as Starbucks Wi-Fi hotspots are not trusted and Windows computers will not be discoverable on those networks by default and may not appear in the Master Browser's list of network resources.
>
>A client computer using NetBIOS UNC syntax goes out to the Master Browser and asks it for the low-level network parameters needed to access the requested \\servername\sharename . If the client can find the Master Browser, and the Master Browser has the required information, then this syntax will work.
>
>It works fine on networks where the client and the server\share are on the same IPv4 subnet. However, NetBIOS is ancient and was not designed to be routable, so if the client and the server\share are on different subnets then it may not work. A VPN or static routing *may* allow it to work, but they would need to be able to support NetBIOS, and if so that support may need to be explicitly enabled. NetBIOS is regarded as having security issues so it's disabled by default in some routing and VPN products.
>
>The site that's using FQDN UNC server syntax may be doing so because they're on a different subnet and/or NetBIOS UNC syntax can't be made to work in their environment. Windows itself supports that, so it can find your EXE and start it (so to a sysadmin it looks like everything's OK), but internally VFP can't use that syntax.
>
>3. \\IPv4ServerAddress\ShareName\FolderPath\FileName e.g. \\192.168.1.100\sharename\appname.exe
>
>This syntax is useful for testing because it doesn't depend on any NetBIOS lookup and it directly queries the target server. You can also use this syntax in production as long as:
>
>- the specified subnet/IPv4 address is reachable
>- the specified server has a static IPv4 address
>
>If for any reason your customer's IT admin doesn't want to map drive letters, they could use this syntax instead. From what you've already said it sounds like the above conditions have been met so it would be an option, at least for testing.

I was reluctant (call it embarrassed) to write to the customer IT that my application does not work with FQDN.
And since you are saying the NetBIOS UNC is a ancient; so I will not ask for it. But I can ask them if they can map the driver to a letter, just for those users that are on a different network and can only access the share via FQDN.
Again, thank you very much!