A community of more than 1,600,000 database professionals and growing

Built in accounts are both a help and and a hindrance. Years ago I was working on a SQL Server 4.2 system, where I was an administrator. The database was very unstable, and we were trying to determine if it was something being done by the application or the platform itself. While I was a local administrator, I couldn't access other, remote SQL 4.2 instances at other locations for our company. Since we ran the same code (supposedly), we wanted to test how various parts of the system performed between the two systems.

One late night, while actually reading the manual, I discovered the "probe" account, which was a built in account for early Sybase/SQL Server versions. I used this to query remote instance and compare settings and performance. This helped us narrow down the the problems, though it wasn't the way I would have wanted the system to work.

Any built in account allows some ease of getting an application working, but it also provides a known backdoor to your system if it is not properly secured. The "sa" account is one of those well known accounts for SQL Server that can cause issues. This account has complete control over SQL Server, and even though it can be renamed, simple queries can discover what the new name is and mount attacks. This is one reason why many people like to only enable Windows Authorization, preventing anyone from logging in with this account?

However, is this enough? I don't think so, as a simple administration action could enable mixed mode authentication. I would say that everyone should set a long, random password for "sa" on all instances, but what do most of you think? Do you provide any other protections for the sa account? Let us know today.

Join the debate, and respond to today's editorial on the forums

What we are looking for is a person that has a row with Rock, a row with Paper, and a row with Scissors at a minimum. The person could have multiple rows of any of those, but they need at least one of each.

This type of query is looking for a distinct list of 3, since we don't care if someone has two rows with Rock, as long as they have a row with Paper and a row with Scissors. We want this distinct list to equal the scalar, and since this is an aggregate, we use the HAVING clause.

Thus, we use this query:

 SELECT rg.Person FROM dbo.RPSGame AS rg GROUP BY rg.Person HAVING COUNT(rg.Played) = 3

This will return a user that has at least 3 rows with different values for the "played" category.

This this player is returned:

 Person GameID Played win ------ ------ -------- --- Ashley 199 Paper 0 Ashley 266 Scissors 0 Ashley 321 Rock 0 Ashley 881 Paper 1 

But not this one:

 Person GameID Played win ------ ------ ------ --- Bill 223 Rock 1 Bill 444 Rock 1 Bill 704 Rock 1 

Ref: GROUP BY - https://msdn.microsoft.com/en-us/library/ms177673.aspx

GROUP BY Basics - https://www.simple-talk.com/sql/t-sql-programming/sql-group-by-basics/

» Discuss this question and answer on the forums