>>In order to test if the VFP 9 application has a problem with the Internet/FQDN-style UNC, I created a log (last night) that records who opened the application, from which PC, and what was the the value of the
>>

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

>>when application started. That is, what was the Target of the application in the desktop shortcut.
>>
>>The results are as following:
>>During the entire day today (the customer is in Europe, so it is already evening there) 6 users started the application from the internet/FQDN-style. That is, for these events the log file shows the value of:
>>

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

>>
>>And not one time - out of these 6 times - an error occurred.
>>
>>Therefore, I am wondering, does VFP 9 have the problem with the FQDN-style UNC sometimes but not all the times? Because, clearly, it does not have the problem all the time. And if this is true, the problem happens sometimes, what could cause the problem happen?
>
>Some more speculation...
>
>Your original post referred to "\\servername.organization.healthcare\appfolder\libs\dl_error.vcx" . Maybe that's an error handler which is supposed to be called or invoked when some error happens? If that's not working properly for any reason, errors might not be recorded. So, although errors may actually be occurring, you don't see anything logged so you think there are no errors (?)
>
>Error handlers must be bulletproof and fault-tolerant. Maybe there's an issue in your handler (?) For example, maybe you report the server name. If the code getting that is expecting a NetBIOS-style UNC with no dots in it, maybe it blows up if there is a FQDN with dots (?)
>
>Antonio may well be right, that you get the error if there's a network disconnection or glitch. This is more likely to happen with a WAN (e.g. VPN or static routing) than a LAN. But if you want to be able to report this type of error, your handler must not depend on a network connection being available:
>
>- Your error handling code would need to be local. This would be one reason to run your EXE locally and use a launcher/update system to keep local EXEs up to date
>- You could stage error reporting to the local temp files folder ( SYS( 2023 ) ) and then attempt to write to the server. That way if nothing shows up on the server you could get the user to check their temp files folder

Thank you. I think it makes sense that the error manager should be bulletproof.

I am also thinking of the following cause the problem with the error manager.

The application relies on a configuration file (xml) for pointing to the application folder/share. But this setting in the configuration file is based on the UNC. For example, in this particular case, the configuration points to the folder:

\\servername\applname

Yet, with the application started from the FQDN-style UNC and the error occurs, the code uses the \\servername\appname folder. And this folder is not found because the application started from the FQDN-style UNC. Hence the error is not caught.

Therefore, I am thinking that instead of relying on the configuration file, the application should rely on the Target folder (in desktop shortcut). That is, the application should rely on where the application started instead of the value in the configuration file. Then, the application and the error handler would work for either case: application started from \\servername\applfolder or \\servername.organization.healthcare\appfolder\.

Does it make sense?

UPDATE. After reviewing the error log, I am not sure if the approach above makes sense. The error log says that the error cannot file the error library (dl_error.vcx) in the folder \\servername.organization.healthcare\appfolder\. That is, not the folder specified in the configuration file but the folder specified in the FQDN-style UNC. So, the program somehow uses the right folder but still error.
Therefore, the error could be caused, as Antonio Lopes said, by network glitch.
That is, it does not matter where the error is logged, locally or on the network, if the library is not found (which is in the executable), I cannot see how the problem would be resolved.