Multiple users not seeing each other's changes or undoing them

[brookeewhite1]

This is an old thread, but I wanted to come back and close the loop on how the problem was solved. Our tech support indicated there was an issue with accessing SAS through a different operating system and they had a potential fix in mind, but it would have changed how many other users interacted with the system, and they didn't want to do that. So we ended up using a workaround instead.  Instead of saving our SAS project *.egp files to the SAS Server, we save them to our shared drive.  Since they are now stored within the Windows operating environment, an error appears when a user tries to open a project already opened by another user.  We still save our data files in the SAS Server, it is only the *.egp files we moved to our shared drive.

[CaseySmith]

I suspect the difference is the way in which the EG project files are being accessed.  If they are accessed through the local file system (which includes UNC paths), there will be a file system write lock on the file, thus additional people who open will only be able to open it "read-only" (what Tom is seeing).  Whereas, if the EG projects are accessed through the SAS server (ex. SASApp->Files), there is no file system write lock, so no realization that another user currently has it open.  I suspect this latter case is what you are running into.  We are working on handling this scenario better in a future release.

[brookeewhite1]

CaseySmith, I can confirm we access our files through SASApp->Files. I have no idea if that is something we can change or not, since all of our SAS tools are accessed through our contractor.

TomKari, I'll try to come back and post the resolution once attained, however it may be a while. Our help desk closed the initial support ticket and transferred the issue to an ongoing issues list that deals with problems not easy to fix.

[ChrisBrooks]

Firstly I'd agree with @Reeza that EG projects aren't designed to be developed by more than one person at a time and attempting to do so could well be a recioe for chaos. I'm also not sure that version control would solve the problem either. It would certainly be valuable (one of the first questions I ask when starting on a new project is what version control system we can use) but one of the fundamental things it does is attempt to reconcile changes in the files (a process called merging) and I doubt that would work effectively in an EG project as it's not a straight text file.

One thing you might try is having each person work on a discrete portion of the project in a seperate process flow in their own version of the project and then when required manually copy that into the "real" project. It's not perfect and would require real discipline among the developers but it might be the best you can achieve.

There's a blog post showing you how to copy process flows here http://blogs.sas.com/content/sasdummy/2015/07/08/copy-process-flow-enterprise-guide/

[brookeewhite1]

ChrisBrooks,

Thank you, I was able to copy a process flow from one project to another successfully for the first time today. (The trick was figuring out how to have two projects open at once and I did this by opening 2 instances of EG.)

I don't think this solves the issue we have today with 2 people working in the same area - we need to have more than 1 in an area since one is reviewing the other's work - but this is definitely a helpful tip for some other uses. For example, we have some user defined formats that we could group in one process flow and share between projects.

Thanks!

[LinusH]

What kind of processing do those projects perform? If it's data prep and similar you probably need an ETL tool, like Data Integration Studio which has check-out/check-in OOTB.

[brookeewhite1]

LinusH, it's a little importing/cleaning of data but mostly analysis. We have one person creating routines and another checking them and not so much editing as adding comments. Fortunately there are only 3 of us right now so we can verbally check with each other to see who is active, but going forward we'd like a more robust process to prevent accidental overwrites/lost data.