>>>>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.
>
>The same app on the same server\share is being accessed using different invocations from 2 different environments. But, you have only 1 config xml file which is being used by both. That doesn't sound ideal:
>
>- As you suggest, one way to address this would be to use the EXE's starting folder rather than relying in the value in the config xml file
>- Or you could use separate/custom config xml files for each environment
>
>I've been speculating that VFP may not (fully) support FQDN-style UNC addresses. Can you do some testing to check this:
>
>- For users(s) using FQDN, try ADIR( ) and FILE( ) with FQDN-style UNC to look for a file that you know exists and is not built-in to your EXE
>
>Either test might bomb out with a syntax or some other error (i.e. not supported). OTOH if the tests work and return the expected result then maybe VFP9 does support FQDN-style UNC addresses.

First, I already made the change to the program so that it would support two (or more) configuration files. Simply by passing to the .EXE the name of the second (or third) configuration xml file. And maybe I will do it. It will just require the System Engineer to add this parameter to the desktops of the users. How many I don't know. So, he may not like the idea.

As to your test. Yes, I can add some code to the program and write into a log, without the customer knowing what this is happening. I will do it tomorrow and install the update. I should know the results by the following day.
Thank you.