Showing posts with label SQL Server. Show all posts
Showing posts with label SQL Server. Show all posts

8.08.2013

How to add a program exception to Windows Firewall for SQL Server

Every now and then when installing a new instance of SQL Server you may want to connect to it from other machines via Management Studio.  Here are the instructions on how to do that.  


To add a program exception to the firewall using the Windows Firewall item in Control Panel.

  1. On the Exceptions tab of the Windows Firewall item in Control Panel, click Add a program.
  2. Browse to the location of the instance of SQL Server that you want to allow through the firewall, for example C:\Program Files\Microsoft SQL Server\MSSQL11.\MSSQL\Binn, select sqlservr.exe, and then click Open.
  3. Click OK.

5.04.2010

A SQL Server Cursor example

Every now and then the need to write a SQL Server cursor comes up.  Since I find myself going back through a labyrinth of code when this happens, I thought it would be a good idea to post it here.  That's if I remember to look here the next time I need to create one - which just might be several seasons later.

*The humorous thing about this is that as I went to SQL Server Management Studio to copy the cursor example, it was gone.  Apparently, I closed the script window immediately after running it thinking I wouldn't need to use this in a long time.  No worries though, I wrote this up again in a short time.


declare @SOMEID int
declare appcursor cursor FAST_FORWARD
FOR SELECT Table1ID FROM tblTable1

open appcursor
fetch next from appcursor into @SOMEID
while @@fetch_status=0
begin

delete 
from tblWhatever
where WhateverID = (
select top 1 WhateverIDFK
from tblSomewhere
where SomeID = @SOMEID
order by DateOfEntry
)

fetch next from appcursor into @SOMEID

end
close appcursor
deallocate appcursor

One thing to note is the FAST_FORWARD hint.  You should always declare this when you need a forward-only, read-only result set.  FAST_FORWARD allows you to traverse the dataset with the least amount of overhead.  Cursors are generally slow because of the nature of their use.  Most times, you are forced to use a cursor because you have seemingly no other way to perform certain database actions, which frequently require small units of work like in the example above.  In the case where you need to update a result set, consider using FORWARD_ONLY (only use fetch next).  Please see this MSDN article for more information on cursor types.

6.17.2009

Orphaned Users in SQL Server

It happens all the time - orphaned users. Often times you are required to restore a database for testing purposes and you go back to your land of semicolons, butterflies and ponies and all of a sudden BAM: Login failed for user 'dbuser'.

In SQL Server, Database Users and Server Logins are two different entities. Users are associated to the database level, and logins are associated to the Server level. Every User must be mapped to a Login. Otherwise, you get a dreaded orphan.

In SQL Server 2008, run sp_change_users_login @Action='REPORT' to detected orphaned records. I actually just ran this and there are three orphaned users in one of my databases right now. Slacker!

To resolve an orphaned user, run sp_change_users_login @Action='update_one', @UserNamePattern='DatabaseUserName',
@LoginName='ServerLoginName';

And there you have it. Happily reunited.