06-19-2013 05:49 PM
Hello. In general when you try to input a csv file through an infile statement, if someone has that csv file open, you get the error "The process cannot access the file because it is being used by another process"
This is using Base SAS
windows 7 environment
accessing a file on a shared network drive
Is there a known way around this issue? I have to read this file on a specific timing basis, however it is highly likely that someone will be using this file at the time I need to open it.
Would the only solution be to make a copy of the file using the command line from with SAS, and then read in that copy of the file?
As always, thanks for the help!
06-20-2013 07:47 PM
06-20-2013 06:43 AM
I think you will find that the other person has the file open in MS Excel, the Windows 'default' application for CSV files. Excel locks any file it has open. Normally text files can be read by multiple users, but Excel locks in case any changes are made.
Talk to your systems admin to see if there is a solution whereby the file can be kept in a folder where only you have write access. You only need read access, but anyone else wanting to read the file in Excel will be forced to make a copy.
06-20-2013 10:06 AM
Hi Richard. This is what I had feared. Unfortunately other people need to be able to access the Excel file in question to make changes to the base data with in, which will then be loaded into a database.
Okay, it looks like I will be forced to write the code to make a copy of the file first (this can be done even while locked from Excel, not sure why that is), and then read in the data from the file copy.
06-20-2013 10:44 AM
On UNIX there is FILELOCKS system option that would allow SAS to ignore the lock and read the file. I could not find that option documented for Winders. You might try it might work.
06-20-2013 10:52 AM
Is it a problem that you might not get the latest data in the copy?
I dont have a lot experience with people actively updating csv files, but I imagine the data in the copy would not have the updated information. Could you move it to Access?
Just a thought!
06-20-2013 10:55 AM
It is actually not a problem if I do not get the latest data, as the process is set up dynamically to update data as of the grab time (even if someone is working in it, or at least it would be without the locking problem).
Sadly Access is not available as a solution.
06-20-2013 11:20 AM
So I have done quite a bit of testing, and it turns out as long as you use a call system option, SAS can copy any file regardless of its locked status.
As such, I will simply use the following code, and then use the newly copied file as part of my coding solutions in the future.
OPTIONS NOXWAIT XSYNC;
CALL SYSTEM ("copy ""G:\Input File Template_6.19.13 v1.csv"" ""G:\Input File Template_6.19.13 v1 test.csv""");
This is a 'easy enough' way to get around the problem of file location, while the only cost is the time it takes the command line to create a copy of the given file (not to bad in this instance since the file will only get to 100 MB max).
Thanks for the help everyone!
06-20-2013 07:47 PM
Need further help from the community? Please ask a new question.