>>>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)))

Again, thank you!