>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