September 6, 2016 at 11:56 am
Our problem was just solved by merely installing SQL 2012 Management Studio; previously we had SQL 2008 version and from the install path, I'd even say SQLExpress was involved.
We didn't change any permissions; we didn't GRANT, REVOKE or DENY anything. It had nothing to do with permissions in our case.
Kris
September 6, 2016 at 12:19 pm
kweiskittel (9/6/2016)
Our problem was just solved by merely installing SQL 2012 Management Studio; previously we had SQL 2008 version and from the install path, I'd even say SQLExpress was involved.We didn't change any permissions; we didn't GRANT, REVOKE or DENY anything. It had nothing to do with permissions in our case.
Kris
Are you connecting to a SQL 2012 instance? If that's the case, it has nothing to do with permissions but it is due to using the wrong version of SSMS.
SSMS is backwards compatible, not forwards. There are metadata and system changes in 2012 that SSMS 2008 doesn't know how to handle. There are plenty of other things that won't work when using SSMS 2008 connected to a 2012 instance. Just being able to connect doesn't mean it will work correctly. That's why it's not supported.
Sue
September 6, 2016 at 12:28 pm
Yes Sue, it's a 2012 back-end. You're exactly right, as that was our issue.
I don't think we uncovered this in the past, I guess because previous users with the 2008 SSMS, they were DB Admins?
If nothing else, I'm glad we got it solved and learned in the process that it wasn't a permissions issue, as I see many on this post who were still having the issue and permission changes, etc were having no impact. Now we know why and hopefully this will help others.
Kris
September 6, 2016 at 1:05 pm
kweiskittel (9/6/2016)
Yes Sue, it's a 2012 back-end. You're exactly right, as that was our issue.I don't think we uncovered this in the past, I guess because previous users with the 2008 SSMS, they were DB Admins?
If nothing else, I'm glad we got it solved and learned in the process that it wasn't a permissions issue, as I see many on this post who were still having the issue and permission changes, etc were having no impact. Now we know why and hopefully this will help others.
Kris
I think you just didn't find out because of how they use SSMS...indirectly kind of a good thing. I read posts on various forums of people hitting issues with the same setup when they were using older versions of SSMS to do queries for them, whatever it's called when you do select top 1000 or edit top 200 selecting a table in the GUI. They got plenty of odd errors. Most admins (hopefully) don't select or update data this way so I would guess that may be more likely why you didn't see it before. They were likely more just executing queries, less reliant on the GUI portion of things and wouldn't notice some of the issues.
Glad it's revolved now though - thanks for posting everything along the way, that really helps others a lot.
Sue
September 8, 2016 at 7:40 am
kweiskittel (9/6/2016)
Eric, Did you see my first post right before yours? How do you explain that? Very odd yes?It's the same SQL account; one user can see the tables, the other user cannot. I don't think it's related to permissions, etc. I've never had to explicitly set permissions for a public user to merely see tables, especially when they have the db_datareader permissions.
Kris
OK, apparenting some of you are experiencing an issue where two users with the same permissions, perhaps even the same login account, are seeing different objects displayed in SSMS. It would be interesting to run a SQL Profiler trace on all T-SQL events to capture what differences there are in system schema queries while each user navigates the database in SSMS.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply