I am trying to debug a procedure on SQL Server 2016, but without success. I asked the support team about permissions and they said that my user has all the permissions. Here I attach some prints about the messages being displayed by SSMS. HResult E_FAIL Error.
Print 1 Print 2 Print 3
Related
I've been running into an issue in R Studio with a SQL connection.
We've had an on-prem SQL Server that's been upgraded over the years, and a colleague that set it up no longer is with the organization.
We also have an Azure Server that's loaded with a SQL Server as well that was much more recently set up before they departed.
We have a GUI program we're currently developing, and one of the early steps is a SQL Login connection for the user where the variable is declared (db_user) and changes with their login and passes the password correctly within system variables defined in .Renviron as posted on RStudio's site for references.
Our initial connection string looks like this, and this is the line of code that starts the connection and where I believe the issue may lie first:
db_conn_onprem <- DBI::dbConnect(odbc::odbc(),
Driver = "SQL Server",
Server = Sys.getenv("server"),
Database = Sys.getenv("database"),
UID = Sys.getenv("db_user"),
PWD = Sys.getenv("PWD")
Whenever the Azure connection succeeds, it connects as dbo#Azure\Azure vs On-Prem's guest#Server\Server.
(I can't post in-line screenshots yet)
On-Prem Connection Screenshot: https://i.ibb.co/PmbGt5y/RStudio-SQL.png
Azure Connection Screenshot: https://i.ibb.co/WFY3FqZ/azure1.png
I feel this is something dbo-related since that's where the connection drops.
(variable names anonymized)
Now for the issue:
Whenever we attempt to run a series of queries, our on-prem errors out with this:
Error: nanodbc/nanodbc.cpp:1655: 42000: [Microsoft][SQL Server][SQL Server]Cannot execute as the server principal because the principal "db_user" does not exist, this type of principal cannot be impersonated, or you do not have permission.
<SQL> 'EXECUTE AS LOGIN = 'db_user' SELECT name FROM master.sys.sysdatabases WHERE dbid > 4 AND HAS_DBACCESS(name) = 1 ORDER BY name ASC'
However, run the exact same procedure on the SQL Server in Azure with relatively no major configuration, and it succeeds.
Here's the SQL Code we run:
EXECUTE AS LOGIN = 'db_user' SELECT name
FROM master.sys.sysdatabases
WHERE dbid > 4
AND HAS_DBACCESS(name) = 1
ORDER BY name ASC
I feel like I've exhausted my resources for this, first I thought it was the initial R code or possibly SQL Drivers, however I don't believe that to be the issue since the SQL driver pulls a list of names in R Studio in the Connections context menu, but bounces back the error when attempting to complete the query.
Whenever I'm searching errors for references for this error, I see
Cannot execute as the server principal because the principal "dbo" does not exist, this type of principal cannot be impersonated, or you do not have permission.
Listed as the most commonly related error for the one I'm experiencing, however I've tried a number of those (From blank DB ownerships to unrelated solutions), but I've mostly hit a wall here.
Any assistance would be greatly appreciated.
I feel this is something dbo-related since that's where the connection drops, but I have no clue where to continue going on this issue.
Yep.
This
EXECUTE AS LOGIN = 'db_user'
requires impersonate permission for the login. Which the error message is clearly telling you. It's unclear why you want to impersonate that login instead of simply connecting as the login to begin with.
Trying to setup an alert in SQL Server 2016 for Severity 015 (syntax errors in SQL statements) however it will not fire off. I can generate the error with a bad SQL statement in query.
I have confirmed DB Mail is working and test messages come in as expected. EMail setup and valid operator in place. I was also able to generate a 017 Alert (insufficient resources) error and get alerted with no problem using the following:
RaisError (N'An error occurred Severity 17: insufficient resources ! ', 17, 1)
With Log
Go
FYI, the reason I need this alerting is we are converting from SQL Server 2008 to SQL Server 2016 and older commands like *= are all over the place. Need to know when they are coming in because of being missed somewhere.
Thanks in advance for any guidance and help.
I'm running a patched SQL 2014 trying to backup a database to one of our Azure Storage BLOBs, using:
BACKUP DATABASE [DB]
TO URL = N'https://storage.blob.core.windows.net/server-mssqlserver/DB.bak'
WITH CREDENTIAL = N'AzureCredential'
,NOFORMAT
,NOINIT
,NAME = N'DBA_DB-Full Database Backup'
,NOSKIP
,NOREWIND
,NOUNLOAD
,COMPRESSION
,STATS = 5
GO
but the query throws the following error:
Msg 3292, Level 16, State 9, Line 1
A failure occurred while attempting to execute Backup or Restore with a URL device specified. Consult the Windows Event Log for details.
Msg 3013, Level 16, State 1, Line 1
BACKUP DATABASE is terminating abnormally.
Checking the server's Event Logs shows the actual error as:
SQLVDI: Loc=IdentifySQLServer. Desc=MSSQLSERVER. ErrorCode=(5)Access is denied.
. Process=4668. Thread=6596. Client. Instance=MSSQLSERVER. VD=.
I have made sure that the SQL Server Agent service's account has the Create global objects policy, and also made sure the SQL VSS Writer service is running under the Local System account. The error keeps happening!
Is there something I can do to fix it, or just log some more detailed error messages than the "SQLVDI: Loc=IdentifySQLServer" one above?
Crikey, this is one of those "no idea how I fixed it" things.
Before I went to lunch, I could reliably generate the error in question by running the provided T-SQL, yet when I came back from lunch the BACKUP command completed fine!
The main thing I remember changing was on the Azure side, where I created a SAS (Shared Access Signature).
This is supposedly not required for SQL 2014 as it uses an actual Azure Credential to connect to the storage instead. I actually created the SAS for an instance of SQL Server 2016 that I want backing up to the same container, and that may have opened the access pathway to the container for SQL Server 2014 too!
Many thanks to Sean Gallardy for recommending ProcMon, which showed a whole ton more error log information than the "ErrorCode=(5)Access is denied" message did.
I have set up a linked server from SQL Server 2008 R2 to an Excel spreadsheet, from which I read the contents in to a table, for comparison during an import.
The spreadsheet is held on a network share from an application server.
Basically, this works perfectly on the SQL Server when I run:
SELECT * FROM SpreadsheetLink...[CONTENTS$]
However, as I now need to schedule this, I need to create an SSIS package on the application server, which runs the same query.
So now, whenever I try to do this though (either by writing the script in to SSIS or by logging in to SQL Server Mgmt Studio on the App server and then opening an SQL connection to the SQL Server and querying directly) I get an error:
Msg 7399, Level 16, State 1, Line 1
The OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "SpreadsheetLink" reported an error. The provider did not give any information about the error.
Msg 7303, Level 16, State 1, Line 1
Cannot initialize the data source object of OLE DB provider "Microsoft.ACE.OLEDB.12.0" for linked server "SpreadsheetLink"
I first wondered whether I had forgotten to install OLEDB12.0 on the application server, but it is there.
I next wondered whether it was a permissions issue, so I added the EVERYONE group, with "Full Control" to the folder containing the spreadsheet and also ensured that the account that I am both logged in with and running the query as is an administrator on both the SQL server and the Application Server.
I also checked that the account was a member of the Distributed COM user group on both servers (it was).
Additional info:
I have tried several things, but it still fails.
I added the following
sp_configure 'show advanced options', 1
GO
RECONFIGURE
GO
sp_configure 'Ad Hoc Distributed Queries', 1
GO
RECONFIGURE
I then re-tested, but got the same results (success from the local SQL server, failure from the other server).
Next, I tried creating a different query, referring to the spreadsheet directly by path, rather than by Link-name, but that resulted in exactly the same outcome:
SELECT * INTO TargetTableName FROM OPENROWSET('Microsoft.ACE.OLEDB.12.0',
'Excel 12.0;Database=\\SERVER_NAME\PATH\fileName.xls;HDR=YES',
'SELECT * FROM [sheetName$]')
I also applied all of the suggestions in the following page:
http://visakhm.blogspot.co.uk/2013/12/how-to-solve-microsoftaceoledb120-error.html. But still no joy.
I set up SQL Server 2008 R2 Performance Studio data collection from this tutorial. Data collection appears to be working great but, when I right-click on Data Collection --> Reports --> Management Data Warehouse and then select any of the reports to load, I get the following error:
'Failed to connect to server sql1.myserver.com. --< Login failed. The login is from an untrusted domain and cannot be used with Windows Authentication.'
This is strange because I set up a new SQL login for MDW to use, and I am logged in to SQL Management Studio with a SQL login as well. A look at the SQL logs gives me this:
Date 9/14/2011 11:12:13 PM
Log Data Collection (Query Statistics)
Log ID 179
Source Query Statistics
Collection Set Name Query Statistics
Collection Item Name
Status Error
Runtime Execution Mode Upload
Start Time 9/14/2011 11:12:13 PM
Last Iteration Time
Finish Time 9/14/2011 11:12:13 PM
Duration (ms) 0
Operator NT AUTHORITY\SYSTEM
Package Execution ID
Event
Data Code
Message
Failed to connecto to the management data warehouse server Inner Error ------------------>
Row#: 0 Source: "Microsoft SQL Server Native Client 10.0" Instance: "IP-0AAAEEDF" Procedure: "" Line#: 1 Error Number: 18456 Error State: 1 Error Severity: 14 Error Message: "Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'." Help File: "(null)", Help context: 0 GUID: {0C733A8B-2A1C-11CE-ADE5-00AA0044773D}.
OLE DB Error Record dump end.
If anyone can provide any help at all, it would help me out immeasurably!
Best regards,
Sebastian
There may be some datacollection configuration issue. In my case it is working fine. From error message it is obvious there is some authentication issue "sql1.myserver.com. --< Login failed". So Try to configure data collection with different credentials.