Presumably because you still have an open transaction. Run SELECT @@trancount in the first window. Presumably you already had an open transaction when you issued the BEGIN TRANSACTION in your...

Keep in mind that the EXECUTE AS clause specifies a database user. I assume that you are a member of sysadmin. In that case, your login maps to dbo in...

This article on my web site includes examples for a related problem - having users to start a specific job,

http://www.sommarskog.se/grantperm.html. Maybe it can serve as inspiration?

Having the application using only stored procedures certainly gives somewhat better security, since you don't have to grant direct access to the tables. And if all you want to keep...

It's fully clear what your question really is, but there is no way you can lock out users from doing things only from the application and never be able to...

Apparently, you have a transaction active in your application.

I seem to recall that I saw somewhere that MSOLAP does not support distributed transactions.

This should help

EXEC sp_serveroption LINKED_OLAP, 'remote proc transaction...

pharmkittie (7/1/2014)

---

If I had this setup could I deploy to a server in the domain once I was ready to do QA or publish to production? Thanks.

I assume here...

Neeraj Dwivedi (7/1/2014)

---

Thank you very much for your response. I do agree with you that if we use Integrated security everything can be managed via AD but my SYS and...

Well, as they say in the trade, it depends.

If you have clients accessing SQL Server from a non-trusted domain, SQL logins is your only option. This includes the case you...

Now, that is completely crazy! Many Windows admins would say flat no to having a Visual Studio on a...

Oh, the joys of company politics!

I certainly would not like to have a work computer where I don't have admin rights. But the only advice I can give is that...

They are not logins. They are schemas, and for legacy reasons they are also database users. dbo is dbo, the overall almighty in the database and you can't do anything...

As long as you have db_owner permission in the database, you can do whatever you like. And if you are sysadmin on server level, you are db_owner on database level.

Exactly...

You should keep the login and the group as a user. But you should drop the group from db_datawriter and db_datareader.

Which version (including service pack) does this server have?

For the main instance DB1 the user has permission through group wingroup1. On the second instance DB2 (which is called using the four-part notation) they had no permissions...