SqlException: The INSERT permission was denied on the object '', database '', schema 'dbo'

Question

I have created a back end application which uses Entity framework to connect and write to the database.

Suddenly I am getting the following error: SqlException: The INSERT permission was denied on the object '', database '', schema 'dbo'.

I checked my user which is db owner in the database. Add my user directly to the table itself. I am still getting the error. How can I view it in SQL Profiler which account executed the query? This is a virtual machine and everything is installed using my account.

Edit:1

• The SQL Profiler is running inside the same machine where SQL server is install. It is a completely isolated environment. Everything runs inside the same machine.
• Everything is installed under one account and that is mine account. No other account is used.
• SQL Server Agent (MSSQLServer) is running under NT Service\SQLServeragent
• SQL Server : NT Service\MSSQLSERVER
• My account has sysadmin and db_owner rights on the database
• gave direct access to the tables as well, but still no luck

Answer 1

In terms of capturing the offending batch/query in SQL Profiler, I'd suspect that perhaps you aren't capturing the correct events? If an exception is being thrown, the only way you'd be able to see which actual SQL batch/statement caused the exception would be by including "starting" events (in addition to the more common captured "completed" events).

Running a trace with the following should allow you to see which procedure/statement is throwing the exception if you are capturing the correct events, those you'd want to capture would/could include:

1. SQL:BatchStarting
2. SQL:BatchCompleted
3. SQL:StmtStarting
4. SQL:StmtCompleted
5. RPC:Starting
6. RPC:Completed
7. SP:Starting
8. SP:Completed
9. SP:StmtStarting
10. SP:StmtCompleted
11. Exception

You mentioned you're using EF, so you could likely safely ignore events 5 & 6, and also 7-9 if you're not actually executing a sproc. Be sure you capture all associated columns in the trace as well (should be the default if you are running a trace using the Profiler tool). The Exception class will include the actual error in your trace, which should allow you to see the immediate preceding statement within the same SPID that threw the exception. You must include the starting events in addition to the completed events as an exception that occurs will preclude the associated completed events from firing in the trace.