Is there a way to modify the column program_name in table master..sysprocesses?
I have found two methods, but both set the name during the creation of the connection:
Using parameter appname when executing an isql command
Adding parameter APP= in a connection string when opening an ODBC connection.
I am looking for a way to modify it AFTER it has been created.
I tried the following example:
sp_configure "allow updates",1
go
UPDATE master..sysprocesses
SET program_name = 'test'
where hostname = 'server'
and hostprocess = '23240'
go
sp_configure "allow updates",0
go
But failed:
Could not execute statement.
Table 'sysprocesses' can't be modified.
Sybase error code=270
Severity Level=16, State=1, Transaction State=0
Line 4
You can continue executing or stop.
Changes to column sysprocesses.program_name are not allowed after its been created. But there are three columns in sysprocesses which can be changed after creation of the connection
sysprocesses.clientname
sysprocesses.clientapplname
sysprocesses.clienthostname
Exerpt from the Sybase Infocenter website:
Changing user session information
The set command includes options
that allow you to assign each client an individual name, host name,
and application name. This is useful for differentiating among clients
in a system where many clients connect to Adaptive Server using the
same name, host name, or application name.
The partial syntax for the set command is:
set [clientname client_name | clienthostname host_name | clientapplname application_name]
where:
client_name – is the name you are assigning the client.
host_name – is the name of the host from which the client is
connecting.
application_name – is the application that is connecting to Adaptive
Server.
These parameters are stored in the clientname, clienthostname, and
clientapplname columns of the sysprocesses table.
For example, if a user logs in to Adaptive Server as "client1", you
can assign them an individual client name, host name, and application
name using commands similar to:
set clientname 'alison'
set clienthostname 'money1'
set clientapplname 'webserver2'
.
.
.
Use the client’s system process ID to view their connection
information. For example, if the user “alison” described above
connects with a spid of 13, issue the following command to view all
the connection information for this user:
select * from sysprocesses where spid = 13
To view the connection information for the current client connection (for example, if the user “alison” wanted to view her own connection information), enter:
select * from sysprocesses where spid = ##spid
Using SQL Server 2016, I am trying to configure a user other than 'SA' to import a file. The code I am executing is as follows:
EXECUTE AS USER = 'DataImports';
SELECT CURRENT_USER;
EXEC xp_cmdshell 'TYPE myFileNameHere.txt'
BULK INSERT DataImports.staging_AddressBook
FROM 'myFileNameHere.txt'
WITH (DATAFILETYPE = 'char'
, FIRSTROW = 2
, FIELDTERMINATOR = ' '
, ROWTERMINATOR = '\n');
The error that I get is:
Msg 4834, Level 16, State 1, Line 20
You do not have permission to use the bulk load statement.
I have validated the following:
I do have access to the file as the user required - The cmdshell TYPE returns the rows expected. I do not appear to have a file access issue.
I have INSERT permission on the database in general.
I tested by using:
SELECT
[DatabaseUserName] = princ.[name],
[PermissionType] = perm.[permission_name],
[PermissionState] = perm.[state_desc]
FROM
sys.database_principals princ
LEFT JOIN
sys.database_permissions perm ON perm.[grantee_principal_id] = princ.[principal_id]
WHERE
princ.[name] = 'DataImports';`
I do have the bulk admin role
SELECT
r.name AS [RoleName],
m.name AS [MemberName],
CASE
WHEN m.name IS NOT NULL THEN 1 ELSE 0
END AS IsMember
FROM
sys.server_principals r
LEFT JOIN
sys.server_role_members rm ON (r.principal_id = rm.role_principal_id)
LEFT JOIN
sys.server_principals m ON (rm.member_principal_id = m.principal_id)
WHERE
r.type = 'R' AND m.name = 'Dataimports';
I have even configured the user to be a sys-admin (not part of the long term plan) but I'm still getting the error.
These are the main points that have been highlighted in the other SO tickets and general searches I have performed. I can import the table as SA but not as DataImports despite what appears to be correct configuration.
This is part of a job that is being run and currently we are having to give SA access just to read a file. Security wise this is less than ideal but I cannot work out what is missing.
Any suggestions of what else to check would be gratefully received - all the basics seem to be in place.
Any suggestions
of what else to check would be gratefully received - all the basics
seem to be in place.
Few things:
GRANT ADMINISTER BULK OPERATIONS TO Dataimports
If the destination table contains triggers or checks constraints
GRANT ALTER ON TABLE DataImports.staging_AddressBook TO Dataimports
And
ALTER DATABASE [yourDB] SET TRUSTWORTHY ON;
Because of:
For security considerations, the server-scoped permissions are
stripped down when you impersonate a database user unless the system
administrator has explicitly set SQL Server to trust the impersonated
context at the server-scope. In this case, a login with the control
server server-scoped permission has no permissions to access any
particular database. Therefore, the trigger module that is executed as
this login cannot run.
dxStatusbar1.Panels1.Text :=
DataModule2.UniConnectDialog1.Connection.Username;
...gives me the username that has connected to sql server.
However the connected user has a different name in the actual database.
Example:
His login name for the sql server is 'John' and is user mapped to 'Northwind' database.
However in 'Northwind' database he is called 'John Smith'.
And this is the name (John Smith) I am trying to have displayed in dxStatusbar1.Panels1.Text
after he connects.
How can I get that ?
edit :
Tried Victoria suggestion :
UserName := DataModule2.UniConnection1.ExecSQL('SELECT :Result = CURRENT_USER', ['Result']);
dxStatusbar1.Panels[1].Text := UserName;
but get :
I couldn't find any UniDAC API way to get currently connected user name (not even for SDAC), so I would just issue a SQL command querying CURRENT_USER and grab the name from the result:
SELECT CURRENT_USER;
Or in the Unified SQL way with the USER function:
SELECT {fn USER};
Since you've mentioned stored procedure in your comment, it sounds to me like you probably want to get this information directly from a connection object without using query object. If that is so, you don't even need to have a stored procedure but execute directly command like this:
var
UserName: string;
begin
UserName := UniConnection1.ExecSQL('SELECT :Result = CURRENT_USER', ['Result']);
...
end;
Or in unified way:
var
UserName: string;
begin
UserName := UniConnection1.ExecSQL('SELECT :Result = {fn USER}', ['Result']);
...
end;
One of these might do the job for you. Haven't tested.
SELECT ORIGINAL_LOGIN()
SELECT SYSTEM_USER
SELECT SUSER_SNAME()
Hope it helps.
ORIGINAL_LOGIN: Returns the name of the login that connected to the instance of SQL Server. You can use this function to return the identity of the original login in sessions in which there are many explicit or implicit context switches.
SYSTEM_USER: Allows a system-supplied value for the current login to be inserted into a table when no default value is specified.
SUSER_SNAME: Returns the login name associated with a security identification number (SID).
I am executing a SQL script in SQL Server Management Studio 2018. In my script I need to specify a user (including the domain - unsure if I need the server name).
So I have created a user sam, set the user type to SQL user without login and set the users role to db_datareader and db_datawriter.
I then execute my script but it gives me the error: User or role 'MHT.sam' does not exist in this database.
But I am almost certain I have added this user to the database (see my images below to double check). Is my user and domain name format correct? What do you think I am doing wrong?
Here's my domain and server:
The error is pretty obvious.
In your screen shot in the object explorer you have a user called SAM, but for sp_AddRoleMember you are using MHT.SAM user.
Your sp_addrolemember should also have only Sam something like...
Exec sp_addrolemember N'RunStoredProc' , N'Sam'
GO
Also to double check what your user type is what login it is mapped to and what really is going on, use the following query.
SELECT
d.name AS User_Name
, d.type_desc AS User_Type
, d.default_schema_name AS User_default_schema_name
, d.create_date AS User_Created_Date
, s.name AS Login_name
, s.type_desc AS Login_LoginType
, s.is_disabled AS Login_is_disabled
, s.create_date AS Login_create_date
, s.default_database_name AS Login_default_database_name
, s.default_language_name AS Login_default_language_name
FROM sys.server_principals s
INNER JOIN sys.database_principals d on s.sid = d.sid
WHERE d.name = 'Sam'
I have faced with the following issue: when trying to send email with results of query attached as file, using sp_send_dbmail via executing ordinary query everything seems to be working OK.
But if add the same code into JobStep and run the job, it fails.
Error in job history says
Error formatting query, probably invalid parameters [SQLSTATE 42000] (Error 22050). The step failed.
But when I comment out parameter that refers to file attaching it starts working correctly again.
exec msdb.dbo.sp_send_dbmail
#profile_name = 'profile_name',
#recipients = 'some#mail.com',
#body = 'body',
#subject = 'subj',
--Parameters that refers to attached file
#attach_query_result_as_file = 1,
#query_result_header = 0,
#query_result_no_padding = 1,
#query = 'select 1',
#query_attachment_filename = 'test.csv'
Any suggestions?
I've come to workaround of that issue. Don't know why would it work but never the less. :)
It is definitely about security.
I've investigated that SQL Agent is running on behalf of domain user, say DOMAIN\User.
It has full set of admin rights on server ('sysadmin' server role, etc). SQL Server itself is running under that same user.
The step of job that contains call to sp_send_dbmail runs under the same DOMAIN\User.
Also I've traced that when running the query part of sp_send_dbmail it tries to execute
exec xp_logininfo 'DOMAIN\User' to check against Active Directory if that user is OK. And surprise: something is definitely not OK. This check ends up with:
Msg 15404, Level 16, State 19, Server SQLC002INS02\SQLC002INS02, Line 1
Could not obtain information about Windows NT group/user 'DOMAIN\User.', error code 0x2.
That, with some probability can mean anything about that user's password is expired or user is locked or any other non pleasant things for that guy.
I decided that its to risky to change user for Agent. So I come up to sending mail on behalf of 'sa' which has same 'sysadmin' server role but SQL authorization and omits this AD checking step.
It looks like one user that pretends to be admin to ask the real admin to run dangerous code for him :)
So final code of this job's the first and the only step resembles this:
execute as login = 'sa'
exec msdb.dbo.sp_send_dbmail
#profile_name = 'profile_name',
#recipients = 'some#mail.com',
#body = 'body',
#subject = 'subj',
--Parameters that refers to attached file
#attach_query_result_as_file = 1,
#query_result_header = 0,
#query_result_no_padding = 1,
#query = 'select 1',
#query_attachment_filename = 'test.csv'
revert
I had this problem. I am using SQL Server 2008 R2. I got the email sent with more info about the error by adding option:
#append_query_error = 1,
I got the email with this error about permissions instead of my query:
Msg 916, Level 14, State 1, Server SERVER\INST01,
Procedure GetSalesReport, Line 62
The server principal "CONTROLLEDNETWO\sql.service" is not able
to access the database "MYDB01" under the current security co
ntext.
My query was trying to access some tables where SQL Agent had no permissions (actually in my case it has not even access to it).
I fixed it through SQLSMS by adding a new user "CONTROLLEDNETWO\sql.service" to the db "MYDB01" and granting permissions to "select".
This was all helpful thank you. Wanted to share what I was trying to do with the excel(xls) attachment which was put the results in columns. This worked for me by adding the query_result_no_padding = 1, and query_result_separator= ' , '. ( that is a Tab,Tab in the ticks )
#query_result_header= 1,
#attach_query_result_as_file = 1,
#query_result_no_padding = 1,
#query_attachment_filename = 'TestPriceFlingerReport.xls',
#query_result_separator= ' , ',
#profile_name = 'Test Exchange Server'
EXEC msdb.dbo.sp_send_dbmail
#profile_name = 'Main Profile',
#recipients = 'me#vwp.com',
#subject = 'Test',
#body = 'this is a test',
#execute_query_database = 'myTargetDatabase_mscrm',
#query = N'SELECT * from myTargetDatabase_mscrm.dbo.SystemUserBase',
#attach_query_result_as_file = 1,
#query_attachment_filename = 'Test.txt'
For reference, this failed repeatedly showing as invoked as the domain administrator, but run as local\sqladmin. After flipping variables off an on and trying to give permissions, I saw in the script of the job that it was still using the master database. I found the setting staring me in the face. It's in the configuration for the Step. I changed it to msdb and it worked. Keep in mind that I changed the select from myTable to select from myDatabase.dbo.myTable based on some posts. That may or may not have contributed to fixing the problem. I also used #execute_query_database to make sure it's running the query from the right place. Again, that might not have been necessary.
No matter what finally made it happy, it had nothing to do with whether it was attaching or not.
in my situation, It could not identify the table belongs to with database. Once the database.dbo.table was added to the query it worked.
When you manually execute your query, YOUR credentials are used. When SQL Agent executes the same query, the SQL Agent service account's credentials are used. By default, SQL Server Agent will use the LocalSystem account credentials. One way to fix the problem would be to change the user under which the SQL Server Agent service is running with a user that has access to your csv directory\file.
I believe this problem was due to a change implemented in SQL 2008 and later regarding locking down security for just the sp_send_dbmail.
It only happens if you pass a qry to send_dbmail to execute, and return the results thru the email. The problem is the error message is misleading and not appropriate.
A good solution is to create a SQL user with just the minimum necessary permissions to perform that query. For example, db_reader, or db_writer, and db_owner if absolutely necessary. And make that user the owner. You can also create a SQL credential and configure that sql job to run under that SQL credential.
I had this problem too, and solved it in two parts using much of the advice here.
1) Right-click, 'View History' on the job showed failure details, and the failure notice gave the name of the user the job ran under, so I gave this user read-only access to my DB.
2) I had forgotten to specify DBName.dbo.MyTableName and was using MyTableName only.
Incidentally, the emails were all going to my junk email folder.