I do not know if Tech Support has a clean up tool. I recommend starting a support track to get assistance on cleaning up the deployment so you can start from a clean slate. Mark ... View more

Hi @K_Osborne - That is frustrating that the EG install is failing. The error, 1603, indicates a failure in one of the actions used to setup the system after the EG files have been copied to the install folders. Given that you say the profile was rebuilt, I recommend the following: Try running the installer with elevated privileges (run as administrator). It is possible there is some file that needs to be updated that can't be now because it is owned by a different user or permissions are wrong, etc. If that doesn't work, then I suggest contacting SAS Support. There are ways to edit the registry and to delete filesystem content to manually remove EG, but it is best to do that in the context of a track instead of instructions posted on the web. Hopefully, running as admin will resolve the issue. Regards Mark Allemang ... View more

I recommend: * Opening a support track with SAS Tech Support * Include an EG log file of a session where you try to create/modify a job and the trigger page is missing. Until a cause and resolution are found, I think you will need to create the job in EG, and then edit the trigger directly in the Windows Scheduler. When scheduling a job, EG just opens the Windows scheduler. So, it is very puzzling that the Trigger tab is not shown in both cases. Thanks Mark Allemang ... View more

@Michael_W  - I understand and you are correct about needing to get the root issue solved. I'm not involved with the implementation of the procedures like PROC IMPORT, so that is why I suggest reopening your track with this new info. They will be able to get the right people involved to find out the root cause. When you open the track, indicate it is in SAS Foundation, instead of starting with the EG support.   Glad to help. Hope they are able to resolve it quickly. ... View more

@Michael_W  - one more thought....   If you open or run proc print on SASHELP.VEXTFL it will show the active filerefs in the workspace. I suspect when you encounter the problem, your excel file will be listed as one. That will further confirm that it isn't getting cleaned up by proc import. ... View more

@Michael_W  Based on what you have learned, I recommend opening the track again with tech support with this new information. I suspect there is a problem in PROC IMPORT that results in the file access not being closed in the scenario you are hitting. Tech support should be able to route that then. Key points for the track are that the problem happens in both EG and SAS Studio, and ending the workspace session causes the lock to release. ... View more

Yes, that completely resets your session, so environment variables, librefs,etc are all reset. So it likely is not a good workaround for you. ... View more

Hi @Michael_W  In EG, if you right mouse on a connected server, there is a menu item to disconnect. That ends the workspace process on the server.   The same thing can be done in SAS Studio:   (I think this is in all versions..... I only have the Viya 4 version right now.) Options -> Reset SAS Session   Your tests so far have eliminated EG and Studio as the sources of the lock. I suspect the other poster here is correct and something about the error condition may be causing the lock to not be released by proc import. If we can confirm that, then it will make it easier to get the tech support ticket routed to the correct development team. ... View more

Does the trigger page show when you open the scheduler directly from Windows? Type "schedule" in the start menu search and open the scheduler. Then click to "Create Task..." (not Create Basic Task.) If that scheduler instance does have the trigger page, then that suggests something odd is happening when EG opens the scheduler.    If that scheduler instance does NOT have the trigger page, then check with your Windows System admin. There may be an OS setting or permission that is blocking your access.   Thanks Mark Allemang ... View more

@Michael_W - I am a developer on EG and just noticed your reply today. Apologies for not noticing this topic sooner.    A few thoughts: It would be very helpful to follow the suggestion above to use Process Explorer. The downside there is that it would need to be run on the server machine, and you may not have access to that. But if that can be done by you or an admin, it will definitely say what process is locking the file. I suspect it will be the workspace session (sas.exe). I have tried to rep without success. You mentioned it is intermittent. Any pattern to the scenario will be helpful as intermittent issues are always much more frustrating to diagnose than repeatable ones are.  If you have access to SAS Studio on that server, it would be interesting to try the same code from there as that takes EG out of the equation. I understand that your overall process that this code node is involved in may prevent running in Studio. I am very puzzled at the difference in behavior between disconnecting the workspace server in EG and exiting EG. They should have the same effect.   But if I read this thread correctly, stopping and restarting the server session doesn't cause the lock to be released. If the only reference to the xlsx file is in the sas code, then EG is not accessing the file. All access is taking place on the server.  Is the file on your project process flow as a node? If so, that could cause EG to access it. If this last point is correct, (shutdown releases but disconnect and reconnect doesn't), then I recommend: Open the track with tech support again. Provide an EG log file of a session when it happens, and you disconnect/reconnect and the lock persists, and then you exit EG. And then confirm the lock is released. Ask them to indicate in the track that you interacted with me on communities and I asked for the logs. That will result in me getting a ticket to track the work from an R&D perspective. That log will help me determine if there is some extra step that is causing the exit to behave differently than the disconnect. I have reviewed the code and do not see anything. I'm sorry this is proving difficult to resolve - I understand it must be very frustrating. Thanks, Mark Allemang ... View more

Figures. Interestingly, I had never seen the behavior and then it happened to me one afternoon at the SAS Innovate conference. So, I think all that does suggest something in the environment. (Or the gremlin moved from your box to mine!) As best I could tell, the delays I was seeing were simply delays on each network call to the workspace server from EG. There are many calls as connections are made and as code is submitted. So "small" delays on each one do add up. In my case, I was connected using Wi-Fi via VPN cross-country to our servers. When those types of delays occur, it is exceedingly frustrating, both when using EG and when trying to diagnose the cause. I have collected all the logs I have on this issue and am going to continue to look at it as I'm able. My recommendation is that if the problem doesn't return for you, then great. But if it does return, please open a Tech Support ticket and provide them with an EG log and the corresponding workspace server log for a session where the delays occur. Also tell them I requested you do that and to please get me involved in the ticket. Then we can pick it up with less delay. Regards, Mark ... View more

Apologies for not responding - I was at the SAS Innovate conference and then was out of the office last week. I intend to look at this more in the next day or two. Mark. ... View more

That is a great help, @kevin_stanford . I will investigate and let you know what I think the next step needs to be. I will do my best to do that today, as I will be at SAS/Innovate for the rest of the week. ... View more