The operating system returned the error (64):

afarr

I am trying to connect to a Nav Database Server (ver. 5.01), and I'm getting the following error:

The operating system returned the error (64):
The specified network name is no longer available.

I have a batch file that I use to create, or re-create, the service. When I run this batch file, the service is

created without problem; I can also re-start the service, and no problem is reported.
I also checked the hosts and services file - the service name is there, in fact the files haven't been modified for

a few months, and the service was working fine till yesterday.

When I specify the database name and network path, instead of the service name, I manage to open the database

without problem. I copied-and-pasted the database name and network path from the batch file mentioned above.

The first time I opened the database this way, I got the "recovering free blocks" message, but after that I

re-created the service and still got the error above when trying to connect to the service.
I make sure to use TCP as Net Type, both when creating the service and when trying to connect.

Does anyone know how to resolve this?

kine

Is the service running under same account under you are trying to open the files?

afarr

No, the service is using the NT AUTHORITY\NetworkService login.
It's always been like that as far as I know, but this problem only appeared last week.
Other services are also running as NETWORK SERVICE, and they never gave this problem.

kine

Yes, but it could be connected to this. Check, that the service account could access the files (check permissions on the files, folders etc.)...

afarr

Thanks for the suggestions, but unfortunately I still can't find what's causing the problem.

The folder and the actual database file .fdb are both giving "Full Control" to "Everyone", so it doesn't look like a permissions error.
The error doesn't say that there's a problem finding the database file, but the network name.

There is another database in the same folder, with its own Database Service (which is also running as NT AUTHORITY\NetworkService), and that service works fine, so it doesn't seem that there's any problem with the folder.

The SERVER.EXE for these two services (and the folders they're in) also have the same permissions.

afarr

We found that this problem is intermittent - we do sometimes manage to connect to the service after restarting VM1, the machine where the service runs - this is different from DYNASERVER, the machine hosting the database, which we haven't restarted.

Something seems to disrupt the connection from VM1 to DYNASERVER.
There are other services on VM1 for other classic databases, and also Database Servers for RTC and WebServices. However, these have worked before, and are currently working well, so it doesn't seem that they are the cause of the problem.