EG: Stop locking files!

[ChrisNZ]

Using EG is like walking on glass shards, so I will not attempt to list all the deep cuts and all the paper cuts one has to continuously deal with. Still, one is annoying and repetitive enough that I must take the time to raise it here:

When deleting a table, one is sometimes told that the table is locked, as seen above.

The table is not visible in the process tree even though it is opened (without being identified) by one of the programs, and the easiest way is then to go back to the process flow view, search for the table somewhere in the flow, delete its shortcut there, and then one can delete the table proper.

Please provide a prompt instead of this ludicrous "unexpected error".

[SASKiwi]

I find it easier to use the "close all datasets before running a process" option to avoid this problem. The downside of course is that you may not want to close all of your datasets every time you run anything, but it could be the lesser of two evils....

[Kurt_Bremser]

It is what happens when the design paradigms of the Dumb Operating System (aka DOS) are followed. It's one of the many major shortcomings of DOS/Windows that files are unnecessarily kept open, and it seems like a contagious illness that affects all people programming under that kludge.

[RW9]

Anyone would think KurtBremser, that you did not like DOS based systems!

Isn't this a process thing?  I mean if I need to do some system work, I would just kick everyone oiut of the system at an off peak time and then do that process.  If its witihin an area, then there would be two distinct areas, a user area for day to day running, and a main area.  Users work in their own areas, and hence have full control over files within that area.  And then in the main area only project owner can run things and have control.  Therefore it should never come up that someone has a file locked.  Just a thought.

[Kurt_Bremser]

@RW9: The problem is that the open files make EG stumble over it's own legs. So a defined "off-line" period would not solve the issue.

In batch jobs, I have solved the issue simply by removing existing .sas7bdat files with rm before writing them from SAS.

[ChrisNZ]

>Anyone would think KurtBremser, that you did not like DOS based systems!

Indeed one could be inclined to interpret @Kurt_Bremser 's comments in this manner!  😉

Not that there's anything wrong with this opinion....

In this case the file is locked by myself as my EG session opened it at some point.

This should not cause EG to trip in such an ugly manner, and a prompt is all that's needed.

[ChrisNZ]

Sometimes, the table is nowhere to be found in any part of EG.

It is just "locked by you" with no way to "unlock" it (except to disconnect the session?)

We need EG to help getting work done, not to get in the way.

[ScottBass]

Agreed with @ChrisNZ:  if EG at one point or another opens the table, and EG is later smart enough to detect that it is locked (with the horrid error message), then EG could be smart enough (i.e. enhanced) to provide a prompt at the point of "failure", allowing you to close the file and then submit your program.  This would be a more fine-grained approach than the sledghammer "close all datasets before running a process" option.

[DaveShea]

I heartily agree with ChrisNZ's suggestion.

If a user asks to delete a dataset in SAS Enterprise Guide and that user's own SAS session has a lock on it, SAS Enterprise Guide should be able to determine this, offer an "Are you sure?" type dialog box and then zap the dataset. The "Unexpected Error" dialog is a bit version 0.00001 for my liking, it is time for it to be replaced with a grown up solution.

Actually, I really think it is about time that SAS Enterprise Guide differentiated between datasets displayed in the Data Grid for read-only purposes and datasets displayed for active editing. I would imagine the majority of datasets displayed in the Data Grid are for read-only access, and, in those cases, there should be no reason for a lock to be on the dataset at all.If a user wanted to edit via the Data Grid, go ahead and put a lock on until the editing was completed.

I would even live with this no-lock feature for just WORK datasets when the locking for read-only really is self-defeating.

As a temporary measure, and to keep things polite, a simpler way of locating the troublesome dataset is to use the Tools->View Open Data Sets menu option and close it from there. This is a bit of a hidden gem in SAS Enterprise Guide and is probably a better solution that either the "close all datasets before running a process" option or the action of disconnecting the SAS session. I have not come across a situation where a dataset that I wish to delete is not visible through this dialog box, but I am prepared to be proven wrong on this one.

Cheers,

Downunder Dave.
Shhhhhh, don't tell anyone, but I quite like using SAS Enterprise Guide..........

[ChrisNZ]

+1 for the so very useful  Tools->View Open Data Sets  information. Thank you!

[Casey_SAS]

We agree that these situations could be better handled  - we're reviewing this idea for a future release of Enterprise Guide