Uniface runtime errors: "Error opening files" "Error reading files"

Have you tried using UNC instead of mapped drive references?

Hi Gianni
About:
.\log\[NETWORK_NODE_NAME]_[PROCESS_PID].log)
The “network_node_name” ist the name of a server or the clients?

What you're describing sounds more like a network issue. In other words, the network (LAN/Wi-Fi) might go down briefly, causing the handles to become invalid. 

As Larry said, use UNC—it's more reliable.

BTW: About the  UNIxxxxx.log output: When ever Uniface got an error to use a Logfile, the fallback is the simple LOG-File in the working directory :-)

Hi Ingo & Larry,

first of all thanks for your replies, here our follow ups:

• It’s for sure that part of or broken sessions are generated from small hiccups in the network; network connectors are sometimes not properly locked into their position and users with a notebook are often moving their notebook on the desk causing their connection to go down briefly. We accept that causes but we do NOT think 100% of the broken sessions are generated in these ways.
• The “network_node_name” is the name of a server or the clients? Yes.
• You both answered directly or indirectly “UNC is more reliable”: under which perspective?
  We made a research about disk shares mapped to a letter before posting our “request for help” because I remember they to be discouraged to be used in the period WinVista / Win7; as of today we did NOT found any post or documents against them. Do you have any link to official documents or field experiences about “UNC are more reliable and better”?
• When a Uniface runtime is shared from a network disk the name UNIxxxxx.log would be better to be changed to [network_node_name]xxxxx.log to avoid potential log overlapping between sessions and to describe the origin of the log file in a more consistent way.

Best Regards,
Gianni

Hi Gianni,

In response to your question: “Do you have any link to official documents or field experiences about ‘UNC are more reliable and better’?”

Over the decades, I have reported many issues to Uniface support and in every situation when a drive mapping was in some way related to the problem, the suggestion was to “try UNC”. That being said, for simplicity, I always use network drive mappings in ASN (and INI) files, but when those fail or are problematic, I use UNC. I tried searching my closed tickets on the support site and it gave me documentation about every product that Rocket makes so completely useless -- that’s a separate issue altogether. I can’t find any documentation at the moment that states when to use UNC over drive mappings or that they are preferred -- I’m not even saying to use one over the other. Instead, I am suggesting to use one when the other doesn’t work. If the problem still persists, then you have to look elsewhere for a solution.

Hope this helps,

Larry

This sounds like networking issue at the root of the issue. A couple ideas/questions:

• Is the ‘L:\’ drive a statically assigned network host? ie. fixed IP. otherwise dhcp release renew and network reidentifying hostname to ip address will cause issues
• Is the 2019 data server hosting the ‘L:\’ locally as fixed storage or is it mapped to something else too? ie. NAS device, CIF storage bucket, NFS some other host
• Is the DNS host recording any spikes or throttling when the log file disconnects? ie. goes to write the file and the system looks up the target host but gets denied because its busy/spiked and breaks the connection (enterprise backups running cause this often or DDOS-like sloppy code or frantic ai agents)
• ‘L:\’ drive disk health? error checking, fragmentation; one bad block can cause alot of headache
• Any SMB monitoring for disk/network showing issues? Mostly not used much/any but can give some insight to disk/network communication health.
• Windows event viewer deep dives at times of disconnection show any resolvable network conditions/timeouts/settings? Sometimes hints and tips can be found in those little yellow warning tags and red log flags previously vetted okay. COM/DCOM filesystem issues or virus tools, security tools can interrupt things in unusual ways.

Some ideas to consider…

Best Regards,

BobK

​@BobK-SIL sorry for this late answer:

1. Is the ‘L:\’ drive a statically assigned network host? Yes
2. Is the 2019 data server hosting the ‘L:\’ locally as fixed storage? Yes
3. Is the DNS host recording any spikes or throttling when the log file disconnects? Good question: I raised it too a question to our sysadmins but the answer I got was: “We did not see anything that should be pointed out from DNS or internal firewall point of view...”
4. ‘L:\’ drive disk health? We verified it and we are maintain it under verification but up to now nothing came up…
5. Any SMB monitoring for disk/network showing issues? Syadmins used their tools and aswered “It is an application issue!”
6. Windows event viewer deep dives at times of disconnection show any resolvable network conditions/timeouts/settings? No events on client side could be traced to be related to this issue; we checked antivirus too but with no luck.

Everything started when the win2019 server was put in place replacing an old win2012 server; shared disk L: was configured already on the old server and was working flawlessly. With the new server in place we started to notice this interruption; end users too started to complain that sessions were breaking. We traced problems for few end users related to unstable network connections due to plugin connectors without the locking clip or cable unstable / twisted… but that’s all.
I feel we should continue to dig into the network layers… I do not feel it is an application issue…

Thanks BobK for your suggestions!

Best Regards,
Gianni