SASRV.INI file no longer contains the server settings

[former_SQLA_member1694870]

We have users reporting an error message (Error: -100) when trying to connect with our databases (12.0.1.3994). Yesterday the MS updates have been automatically applied in the server and the branches also reported internal network issues with their communication service provider.

After a few exploratory steps, we noticed that the SASRV.INI had today’s date/time stamp and all the server connections have been wiped out from the file. The issue was solved after we found a workstation that connected fine with our application via SQLANY12 where the SASRV.INI had not been changed. However, from ISQL the "Find" feature does not list any of the available network services even after fixing the INI file.

Is there  a way to avoid the SASRV.INI to be wiped out?  
If we set the file to READ-ONLY, would it prevent the issue to happen in the future? 
Are there any side-effects on doing so?

[graeme_perrow · Accepted solution]

While I have no idea why the file would have been emptied, the sasrv.ini file is a cache of addresses, used to speed up the search for previously used servers. It is solely for convenience and should not be relied upon. It is not intended to be edited by users.

Bottom line: If you can't connect once the sasrv.ini file has been removed or truncated, then your connection string does not contain enough information.

[former_SQLA_member1694870 · Accepted solution]

Well, this specific customer has users in different sub-nets and only the ones in the main office were able to connect without the the SASRV.INI file. The INI file has been in place in the remote branches for years but was somehow emptied in some workstations. Suggestions?

[graeme_perrow · Accepted solution]

If the server had gone down at some point, and then the clients tried to connect and failed, the address would have been removed from the cache. Then when the server came back up, they wouldn't have been able to connect. This is why relying on the .ini file is a bad idea. The connection string / DSN must contain enough information to find the server.

[former_SQLA_member1694870 · Accepted solution]

Since the branches are in different sub-nets I am not sure if the sasrv.ini file couldn't be avoided without a broadcast repeater. Will try.

[reimer_pods · Accepted solution]

You might want to add the HOST=<IP or Hostname> connection parameter (and possibly DOBROAD=NONE). IIRC this works over subnet boundaries.

[graeme_perrow · Accepted solution]

Reimer's comment is correct, although using "DoBroad=None" can only be done with the LINKS parameter, not HOST. However it is implied (and therefore not necessary) with HOST anyway.