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
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:
SQL:BatchStarting
SQL:BatchCompleted
SQL:StmtStarting
SQL:StmtCompleted
RPC:Starting
RPC:Completed
SP:Starting
SP:Completed
SP:StmtStarting
SP:StmtCompleted
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.
Related
We had several issues during the in-place upgrade from 2014 to 2017, namely the trusted assembly CLR feature that interfered with the successful installation of SSIS at the time. I have since gotten SSIS installed and working, but the feature is still broken.
The error I received at the time, and that I still receive when I query the system table directly is: "Internal table access error: failed to access the Trusted Assemblies internal table". The system view seems to run an OPENROWSET on the "table" TRUSTED_ASSEMBLIES. I don't see a lot of chatter on the internet of people dealing with this problem.
I don't plan on using that feature, but am fearful that it may cause issues in the future with updates or with outside vendors. Another symptom was that in order to fix some of the issues with SSIS package execution was I had to manually assign execute permissions to low-level procedures that are usually done for you (fortunately, the documentation indicated which built-in groups had access to the procs).
If anyone has any insight on the issue that would be appreciated; guessing a tear-down and complete rebuild might be in order.
Have you applied the CUs (Cumulative Updates) for SQL Server 2017? If not, you probably should.
Yes, the "CLR strict security" / "trusted assemblies" "feature" is quite the dumpster fire. Please see my answer to the following question (also here on S.O.) regarding the proper ways to work around the new (as of SQL Server 2017) restrictions (the final paragraph in that answer deals with your situation: pre-existing, unsigned assemblies):
CLR Strict Security on SQL Server 2017
Using module signing you should be able to get everything working without assigning any permissions directly.
As for that particular "Internal table access error" error, that's new to me. I assume you are executing SELECT * FROM sys.trusted_assemblies' as sa or some other login that is a member of the sysadmin fixed server role? If not you would get a permissions error stating:
Msg 300, Level 14, State 1, Line XXXXX
VIEW SERVER STATE permission was denied on object 'server', database 'master'.
Msg 297, Level 16, State 1, Line XXXXX
The user does not have permission to perform this action.
Since you aren't getting the permissions error, it's possible that some component didn't upgrade correctly / completely (hence making sure you have installed the latest CU might check / fix that).
In the SQL Server Audit Add DB User Event Class, there are four Event Sub Classes defined:
Add
Drop
Grant database access
Revoke database access
(MS documentation found here)
When I set up SQL Server Profiler to trace the Audit Add DB User Event Class, it only seems to capture events with a subclass of 3 or 4, and not 1 or 2.
To test the trace, I am using the following SQL statements:
CREATE USER testuser FOR LOGIN testlogin;
DROP USER testuser;
When I run these statements in SQL Server Management Studio, SQL Server Profiler displays two Audit Add DB User Events, one with EventSubClass 3 (Grant database access) and one with EventSubClass 4 (Revoke database access), but does not display anything for EventSubClass 1 (Add) or EventSubClass 2 (Drop).
From what I can tell, all three even subclasses should be covered by the SQL statements used above. Is there something additional that needs to be configured in order to capture these event subclasses?
The old trace functionality has been deprecated since 2012. I did some testing and depending on what commands I executed I could get 2. But I never managed to get 1. If you look at the documentation for this event class, you'll see that it is documented to provide information when you use the ancient procedures sp_adduser, sp_dropuser, etc. But even when doing that it seems a bit flaky.
Sure, one could report this to MS, but they will (most likely) just say that you should use a technology which isn't deprecated. I.e., Extended Events. I very much doubt that MS will pour any resources into fixing this, even if that would consider this to be a bug in the first place. So, my recommendation will be the same: Look into Extended Events instead.
Here's a blog I wrote about "getting into" XE: http://sqlblog.karaszi.com/tips-for-getting-started-with-extended-events/
I have 2 applications connecting to the same database, when starting each individually both are fine. When I start them in the same time one of them will get logon exceptions as you may see below, this happening in 99% of my tries (so very rarely they are fine together).
And it is always the same application that gets the exceptions (1):
an application that's doing queries over the database
an application that connects to the service broker (this one work in all cases)
The 1st app will crash if I delay the start of the 2nd.
Here are some sql server logs:
2015-09-18 07:27:20.43 Logon Error: 18456, Severity: 14, State: 38.
2015-09-18 07:27:20.43 Logon Login failed for user 'domain\user'. Reason: Failed to open the explicitly specified database 'dbname'. [CLIENT: <local machine>]
2015-09-18 07:27:21.32 spid55 Setting database option ENABLE_BROKER to ON for database 'dbname'.
In SQL Server logs it is always like that, 2 line Logon error and then the ENABLE_BROKER line. I'm thinking that the service broker has something to do with the previous 2.
Details about envirenmont: SQL Server 11.0.3153.0 - 64 bit, Windows 7 (7601) running on a VM.
Because your database is in single-user mode. With single-user mode, only one client can connect to the database.
Change it to mulptile-user mode
GO
ALTER DATABASE AdventureWorks2012
SET MULTI_USER;
You can read more for the single-user mode here: https://msdn.microsoft.com/en-us/library/ms345598.aspx?
Finally i found what was causing this, it was the below alter database statement for which I don't see it's usage for now (while using the service broker it should be enabled by the db admin and not each time when the app is restarted). After removing that code everything seems fine.
ALTER DATABASE [dbname] SET ENABLE_BROKER WITH ROLLBACK IMMEDIATE;
Inherited code fun :-) (not)
We are running into a few issues with our TFS installation (TFS 2013 Update 4, SQL 2014 Standard) as a result of email alerts. Most notably, Work Items cannot be created, because this triggers an email.
Any time a process or user attempts to create a Work Item, the error
TF30040: The database is not correctly configured. Contact your Team Foundation Server administrator.
is received. Further, when I check the Event Viewer on the server, I can see the error and it reports that the inner exception is:
Exception Message: The EXECUTE permission was denied on the object 'sp_send_dbmail', database 'msdb', schema 'dbo'. (type SqlException)
I have worked with the DBA and we have enabled Email Alerts on the server. We have verified that, in general, the alerts work by using the test button on the administration console. I can also set up a check-in alert through the web interface and receive said alerts without issue. This seems to be specifically affecting Work Item creation alerts (which apparently are just automatically and irrevocably enabled).
Presumably, we could correct this by giving appropriate permissions to use that stored procedure. To do so, we need to know what user to give permissions to. So far we have tried giving execute permissions to my AD user, the service account used by the build service, and the Network Service account (which appears to be the TFS Service Account).
There is no indication in any error message as to what user is being used to execute that procedure. So, my question: What SQL user is used to send alerts when creating Work Items?
Edit:
For the record, this started working of its own accord. We decided Monday to call Microsoft to get this fixed. Before that happened, failed builds magically created some work items (on Tuesday, a full day after we gave up), and we are now able to create work items. Everyone involved states not doing anything. We are baffled, but in a good way.
I'm going to advise you that a DBA should not be making changes to the TFS databases. I suggest opening a ticket with MSFT and getting assistance from the product support group.
I am using msdeploy (version 2) to transfer a database from machine A to machine B.
On in the database on machine A there are some users that do not exist on machine B, thus the transfer (partially) fails with the message:
Error Code: ERROR_SQL_EXECUTION_FAILURE
More Information: An error occurred during execution of the database script.
The error occurred between the following lines of the script: "3" and "5".
The verbose log might have more information about the error.
The command started with the following: "CREATE USER [someDomain\someUser] FOR LOGIN [someDomain"
Windows NT user or group 'someDomain\someUser' not found.
Check the name again. http://go.microsoft.com/fwlink/?LinkId=178587
The database seems to be transfered, except for the user creation. Does anyone know what state the database is in after this failure?
Is there any way I can transfer the database without the users (or better without specific users) using msdeploy?
Web Deploy uses SMO (SQL Management Objects) to script out and apply the scripts for SQL databases, and exposes most of the SMO settings with the dbfullsql provider (so, most of these options: http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.management.smo.transfer_properties.aspx). If you want to skip the users due to this kind of login-not-exists or user-not-found error, you should be able to do this by adding the scripting option: copyAllUsers=false to the source of the sync. For example:
msdeploy.exe -verb:sync -source:dbfullsql="Data Source=.\SQLExpress;Initial Catalog=MySourceDb;User Id=localUser;Password=LocalPass",copyAllUsers=false -dest:dbfullsql="Data Source=RemoteSQLServer;Initial Catalog=MyDestDb;User Id=remoteUser;Password=RemotePass"
Incidentally, I am surprised you note the db appears to have been sync'd - I would expect this is not actually the case. If you have the permissions for it, Web Deploy will create the database if it did not already exist when it initially tries to make the connection, but your failure occurred very early in the script execution, and I believe Web Deploy dbfullsql syncs are transacted by default (the db creation is separate from the script execution and is not transacted). Thus the db may exist where it did not pre-sync, but I wouldn't expect the data to be present in it.