PC files to connect to Access database: A pipe communications routine failed

[ucdcrush]

Hi all - 

Using SAS 9.4 TS1M5

We (me and several others at a large state entity) have been using code similar to below to connect to Access databases. We are using 32-bit Access databases and 64-bit SAS.

This has been working since we put the code into place many years ago, with many different databases. 

libname dbtest PCFILES path="X:\PCFS_TEST\testDatabase.accdb" scan_text=no usedate=yes;

Something has changed on our systems about a week ago, perhaps due to a system-wide software patch, upgrade etc., that has resulted in our inability to connect to Access using PC files server. We now get the following error in our log file:

ERROR: A pipe communications routine failed: The pipe is being closed. (232)
ERROR: Internal error: unable to communicate with PC Files Server process.
ERROR: Error in the LIBNAME statement.

The first thing I did was to google it, and found some proposed solutions, none of which helped

1) A SAS support item (http://support.sas.com/kb/46/541.html) recommending installing newer ODBC drivers.

* I tried doing the Access 2010 drivers, then the Access 2016 drivers, neither worked.

* Other employees have Office 365, and are experiencing the identical error in the log. So I'm not clear if there is a consistent characteristic of ODBC drivers among the employees.. except none of them work now, when they had worked before.

2) A SAS forum post where the user gave admin role to the process running the task.

* I tried this too, no difference.

3) I upgraded to the latest PC files server, no difference.

The SAS page also suggested it is more likely on network drives. This issue occurs on both network and local drives, so no difference there.

We do have servers running SAS 9.3, running the older PC files server version, and this error does not occur on the servers.

Since we haven't been able to figure it out, we have created tickets with the IT support people in our organization, but they seem to not have many ideas. They rarely deal with SAS or PC files server. We can give them the date at which the issue started, but if they roll out many updates at that time (antivirus software, etc.) then they may not know which one caused it, nor know what to do even if they could pinpoint which one did it.

Strangely, among about 5 employees, for all of them it went away a few days after occurring (and after rebooting), and now it has come back for all of us, rebooting or not. Ideally IT would look to see what changed during these times, but again, no luck with that.

So I'm hoping someone here has had some experience this which might help us get to the bottom of this. I have to think there is some SAS or other system environmental info that might be relevant here, which perhaps we could record in the event that this issue resolves for at least one person. Then we can compare it to that environmental info for the users where the issue is occurring, in order to help track it down. Not sure what else to do.

Any ideas at all are welcome! Though I know we can run certain code on our servers, not all our users have access to them. And our servers are locked down with few ports open to the outside world, and some of our SAS code connects to online to run, so the server wouldn't be able to do that. I'm hoping we can get back to where things were when the PC files connection worked on our PCs.

Thank you.

[Kurt_Bremser]

If you're the one responsible for your SAS environment, open a ticket with SAS technical support.

[Reeza]

Office 365 now defaults to 64 bit, is it possible you're not on a 64 bit version everywhere?
Can you test connecting to an Access DB in other methods - not using PCFILES?

[ballardw]

---

@ucdcrush wrote:

Hi all - 

Since we haven't been able to figure it out, we have created tickets with the IT support people in our organization, but they seem to not have many ideas. They rarely deal with SAS or PC files server. We can give them the date at which the issue started, but if they roll out many updates at that time (antivirus software, etc.) then they may not know which one caused it, nor know what to do even if they could pinpoint which one did it.

Strangely, among about 5 employees, for all of them it went away a few days after occurring (and after rebooting), and now it has come back for all of us, rebooting or not. Ideally IT would look to see what changed during these times, but again, no luck with that.

Thank you.

---

That last paragraph I quote above makes it sound very likely the cause is IT related. I recently had my SAS Online help, loaded locally, start throwing network errors. Some contact with my IT, that "couldn't find the problem" and SAS tech support plus noticing some new security stuff eating lots of clock cycles pointed to the security software blocking access. IT changed a setting and my help was back. For a few days. Then gone. Then back.

When something that was working stops I really try to look very closely at what IT has done recently as they make it very difficult to do anything. Like update SAS licenses, modify the SAS configuration file, apply patches or hot fixes...

I did test my system with a sort of legacy ACCDB file. I no longer have direct access to the ACCESS program but the PCFILES did allow me to read stuff, so that may remove one of the potential issues.

[ucdcrush]

Thanks folks. IT started looking at the update history, and there were a bunch of Microsoft updates to Access and Office done just before the issue started. So they are going to try rolling things back. I think they are doing that experimentally, as they do not want to roll back security updates permanently. So we'll be in touch with our SAS support person to see if we can get PC FS to work with those updates.