BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
ElisabethC
Fluorite | Level 6

When my user refresh data in Excel Addin, all data disappears, leaving them with 0 rows. When I refresh the same report, the rows reappear. The user can see the refreshed data after I have refreshed it and saved the Excel.

 

The log shows no error messages and claims that the background package has finished and the worspace server is alive.

 

One difference I see in the logs from the user and my refresh is that for the user the data set _prodsavail has 0 records, but for me the number of records is 8. But I cannot figure out why this is.

 

In Enterprise guide, the user can see no Libraries (not even WORK). I can assign a library through a libname statement, and the log confirms that the Library has been sucsessfully assigned, but the user can still not see it. The SEGuide_log again shows that _prodsavail has 0 records.

 

We normally use Integrated Windows Authentication, but the results are the same when I enter username and password in the Connection profile.

 

We access SAS through Citrix, but the problem persist when I start EG directly on the server and create a Connection profile for the "problem user".

 

We are on SAS 9.4_M2, EG Version 7.1 HF1 (7.100.0.2002) (64-bit), SAS Addin Version 7.1 HF1 (7.100.0.2122) (32-bit)

 

I understand that there must be an authorization problem somewhere, but I have checked that the user has R and RM to the Library / tables and Read Access to the physical file on the server, and I cannot figure out what is missing.

 

Has anyone encountered this problem and found a solution?

1 ACCEPTED SOLUTION

Accepted Solutions
ElisabethC
Fluorite | Level 6

Hi

Thanks for all your good suggestions. It turns out the problem was not in the users’ access to the folders, files and libraries in question. The problem was that we had a macro called in Autoexec_usermods, that was trying to read informasjon from a library that the user does not have access to. This caused an error, and caused the NOEXEC option to be set, so that the next statement did not retreive any records.

 

We have solved the problem by only running the offending macro if sysuserid is a member of a specific group with the necessary authorisations.

View solution in original post

5 REPLIES 5
SASKiwi
PROC Star

Have you compared the metadata setup for the problem user with a good user? Are they the same?

 

If you assign a LIBNAME in code and the tables don't appear in the server list, that means there could be OS permission problems for the user as LIBNAMEs bypass metadata permissions. I suggest you get them to navigate to that folder outside of SAS and view the contents - are they able to do that?

ElisabethC
Fluorite | Level 6
Hi.

Thanks for your reply. The metadata for the "good" and "bad" users should not be the same, since the good user is a system administrator, and the bad user an end user with only Read and Read Metadata Access to the Library. But I have confirmed that the bad user has OS read Access to the folder on the SAS server. However the bad user is not allowed to log on to the SAS server, so he cannot open the table outside of SAS.


Best regards

Elisabeth
SASKiwi
PROC Star

@ElisabethC - I was more interested on checking the folder permissions for the SAS library with the problem user. Our OS is Windows and in this situation I would ask the user if they can access the folder in Windows Explorer (we have folder shares set up on our SAS servers to allow this). Then if they can access the folder, get them to open a test text file in that folder with any text editor.

 

However I suspect your OS is not Windows so to test folder permissions you would need to do it differently. If you use a flavour of Unix, maybe one of the community's Unix gurus can advise.

ElisabethC
Fluorite | Level 6

Hi

Thanks for all your good suggestions. It turns out the problem was not in the users’ access to the folders, files and libraries in question. The problem was that we had a macro called in Autoexec_usermods, that was trying to read informasjon from a library that the user does not have access to. This caused an error, and caused the NOEXEC option to be set, so that the next statement did not retreive any records.

 

We have solved the problem by only running the offending macro if sysuserid is a member of a specific group with the necessary authorisations.

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 5 replies
  • 1327 views
  • 0 likes
  • 3 in conversation