For a fairly full description of what I'm trying to do, see my previous post at http://www.sqlservercentral.com/Forums/Topic1652109-3412-1.aspx.In a nutshell, I need to restrict users from seeing student information from districts that they are not permitted. So there's a user table that contains the SQL login name and there's a status code. If they're 1, they're superuser and can see/edit everything. Otherwise there's an additional permission table. Originally I had a table called SeekerUsersDistricts that had SeekerUserID and DistrictID, one record per user/district. And that methodology worked just fine. My desire was to reduce I/O, which is probably pointless because I think the cache would handle it just fine, by having a parameter table that would have the user ID and a varchar(255) field that would contain "001,046,010," etc. It would build out the list of permitted districts through either a trigger or a scheduled job.This is the code that doesn't work:[code="sql"]SELECT st.*FROM Students AS stINNER JOIN SeekerUsers AS tON SeekerUserDBLogin = SYSTEM_USERAND (t.SeekerUserRole = 1 OR st.DistrictNum IN (SELECT PermittedDistricts FROM dbo.SeekerUsersReportParams AS td WHERE t.SeekerUserid = td.SeekerUserid))GO[/code](no, I won't use a select * in production)So the question is: (A) is there a way to do what I want to do, and (B) am I ridiculously overcomplicating things and I should be fine with the user ID/district# table.It's difficult to estimate how this table will build out. We're anticipating 1,500-2,000 student records, 90ish district users who can only access their particular district's info, and 100 or so TVIs who work with multiple districts and thus would have multiple records in (B) of the preceding paragraph. But this view is going to be very central to the system and get hit LOTS.
↧