October 7, 2009 at 1:14 pm
There is a known bug with non-sa windows logins and the ability to modify a job.
Verify that 'datcp\willirm' is the same in SQL and your active directory.
select suser_SID('datcp\willirm') -- capture the SID and replace 0x01
select suser_sname(0x01) -- 'datcp\willirM'
Drop and recreate the login to match the results from suser_sname.
SUSER_SNAME() returns the same name/case for the WIndows Login as defined in AD. SUSER_SNAME(sv.owner_sid) which is executed against sysjobs returns the user name in the same case as SQL Server. If both do not match, the buttons in the job properties dialog will be grayed out.
October 8, 2009 at 11:35 am
Just when I thought it was working.....it stopped.
when I follow the above suggestions I get the same login......
When I give the 'TargetServersRole' all the GRANT access on the SP that are used to perform the various operations on the job , the user is still not able to schedule to the job......
This is driving me crazy now....
October 8, 2009 at 11:41 am
This sounds either like a bug, an obscure one, or someone has seriously screwed with permissions in your system.
Do you have an MSDN or TechNet subscription? I might burn a case and have someone dig through the system with you from MS.
October 8, 2009 at 11:57 am
I dont think we have subscription , however I will try to open a case and see what exactly the problem could be . By the way I am running on Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86) .
Viewing 4 posts - 16 through 18 (of 18 total)
You must be logged in to reply to this topic. Login to reply