February 7, 2011 at 3:21 am
I thought "yeah I know this one, I've had this problem, don't even need to look it up"... but I guess with 71% getting it right it's quite a common issue.
Great question, nice start to the week. Cheers 😀
_____________________________________________________________________
[font="Comic Sans MS"]"The difficult tasks we do immediately, the impossible takes a little longer"[/font]
February 7, 2011 at 5:52 am
Toreador (2/7/2011)
I wonder why they are withrawing this procedure?
If I have to make a guess, it is probably because over the past years, there has been a consistent move away from stored procedures toward "real" SQL syntax. In SQL Server 2000 (IIRC), CREATE USER, ALTER USER, and DROP USER did not exist at all; there were stored procs for that as well. One by one, the old stored procs are being replaced.
February 7, 2011 at 6:32 am
Toreador (2/7/2011)
I always use sp_change_users_login in these circumstances...
Ditto. I did get the correct answer, but that's not been my first choice of resolution in these instances.
Toreador (2/7/2011)
I wonder why they are withrawing this procedure? Anyone know if the replacement command does all the security checking that the procedure does?
And ditto again. I didn't realize (until I checked BOL) that this was deprecated. I haven't read page 2 of this thread yet, so if someone's already answered these questions, thank you. If the questions haven't been answered, could someone enlighten us?
February 7, 2011 at 6:34 am
Hugo Kornelis (2/7/2011)
Toreador (2/7/2011)
I wonder why they are withrawing this procedure?If I have to make a guess, it is probably because over the past years, there has been a consistent move away from stored procedures toward "real" SQL syntax.
Real SQL? Why in heavens name would any of us want to use "real" SQL? (And does it taste better than the genuine fake SQL?) :w00t:
February 7, 2011 at 6:45 am
Great question, thanks.
Minor clarification: the 2 hyperlinks listed at the bottom of the explanation didn't contain a notification about future deprecation of the SP (not that I could find, anyway).
That note is present on the page for sp_change_users_login at this location.
Rich
February 7, 2011 at 6:53 am
Good Question. These type of questions will help all of us bursh up our knowledge every day. Thank you again!!!
February 7, 2011 at 7:24 am
I knew exactly what the problem was and could not find sp_change_users_login, so I read the answers to decide which tried to do the same thing and got it correct. To me the value of the question is to educate that the old way we did it is going away.
And as for making the SID identical, well, yeah, this would be the IDEAL way to do it but in the real world, you won't always be administering servers you yourself set up if you get my drift. Always need to know your options.
February 7, 2011 at 8:44 am
Such a bummer to me that the sp_change_users_login option is going to be phased out without a "decent" alternative - consider the scenario that exists in my environment where there lots of sql server logins, and (esp. in dev), you don't document the passwords for them, which makes the ALTER USER solution difficult to pull off. Plus, using sp_change_users_login 'Report' lets you see specifically which users are orphaned before you dive into trying to fix them.
February 7, 2011 at 8:47 am
I have to agree. I like being able to cursor through the proc, having all the orphaned users fixed automatically without any typing. I just open up my saved cursor, execute it, and everything gets fixed.
February 7, 2011 at 8:48 am
Nice question.. And thats exactly a perfect example before reading about Contained Databases in sql server "Denali".
February 7, 2011 at 8:58 am
getoffmyfoot (2/7/2011)
Such a bummer to me that the sp_change_users_login option is going to be phased out without a "decent" alternative - consider the scenario that exists in my environment where there lots of sql server logins, and (esp. in dev), you don't document the passwords for them, which makes the ALTER USER solution difficult to pull off. Plus, using sp_change_users_login 'Report' lets you see specifically which users are orphaned before you dive into trying to fix them.
You don't need the password of the login in order to use ALTER USER. But I agree the report option is pretty handy. Without that you'd need to run the actual SQL statement that sp_change_users_login uses:
select UserName = name, UserSID = sid from sysusers
where issqluser = 1
and (sid is not null and sid <> 0x0)
and (len(sid) <= 16)
and suser_sname(sid) is null
order by name
February 7, 2011 at 9:01 am
Ah, not the missing option of 'wtf are you using sql logins in production for anyway?'
What with them being inherently, disgracefully insecure.
For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<
February 7, 2011 at 9:04 am
RichB (2/7/2011)
Ah, not the missing option of 'wtf are you using sql logins in production for anyway?'What with them being inherently, disgracefully insecure.
For anyone that hasn't I strongly recommend using your favourite packet sniffer (wireshark for instance) to trace the local network while you log in with a sql login. Filter it for login packets... and watch in wonder as your password flies across the network in plain text! <_<
As long as we have vendor apps, or we have people connecting from non-Windows sources, they will be a necessary evil....
February 7, 2011 at 9:35 am
Nice question even if it was long winded. IMHO: Two points is a lot for a question that should be asked and answered correctly at any DBA interview.
This was the first DBA incident I ever had to resolve professionaly. I even got a contract once because the DR plan for a fortune 500 company did not include fixing SQL logins once databases had been restored from Tape to a new server on new hardware in a new domain. FUN!:cool:
February 7, 2011 at 11:08 am
Ronald H (2/7/2011)
Exactly a scenario that happens in our environments. Thanks for the question!
Ditto x 2 :-).
Re the question's phrasing and its choices: since its "you" can successfully connect to Dev using "MyUser", wouldn't the two choices which submit a <NewPassword> make no sense? I answered the question correctly, but I'm just wondering if the right answer could be chosen merely based on that type of analysis of the question. Thanks.
Viewing 15 posts - 16 through 30 (of 39 total)
You must be logged in to reply to this topic. Login to reply