In principle they are the same and are handled the same by your application. The only difference is that NVARCHAR can handle unicode characters allowing you to use multiple languages in the database. NVARCHAR takes twice as much space to store to allow for the extended character set required by some other languages. So if you are not using other languages then definitley use VARCHAR for character data.

Have you ever tried to make sense of how passwords are stored in SQL Server 2005?  It used to be a bit easier in SQL Server 2000.  Back then, the sysxlogins virtual table had a column called password which contained a hashed value of the SQL accounts’ passwords.  Windows’ accounts passwords were always NULL.  Going back to even earlier versions, one of the shameful secrets of SQL Server was that passwords were stored in a clear text file in the SQL Server directory.Now, in SQL Server 2005, the same information is available from the system function LOGINPROPERTY with a property name of ‘PasswordHash’ as described here: http://msdn2.microsoft.com/en-us/library/ms178593.aspx 

and here:

http://msdn2.microsoft.com/en-us/library/ms345412.aspx.

In addition, here’s a great KB support article that explains how to move passwords between SQL Servers, even if they are different versions: 

http://support.microsoft.com/default.aspx/kb/246133

Enjoy,

 -Kevin

As someone who needs to support DB2, Oracle and SQL Server applications and environments, one thing that I always find myself thinking is that one of the nicest things about working with SQL Server is the amount of readily-available information. The problem is, I, like many people, have moments of relative laziness/impatience when I allow myself to accept something I’ve read on the Internet as fact without performing the due diligence to determine whether it’s 100% accurate.

The PSS SQL Server Engineers posted an article (now nearly a year old, but helpful nonetheless) dispelling two of the more prevalent “rule of thumb”-type SQL Server Urban Legends. This is definitely worth a read (especially if you have questions about how SQL Server works with files, or about the disk queue length metric).

On the topic of Disk Queue Length, this is definitely one metric that is used far too frequently on its own to identify an I/O bottleneck. Just as “no man is an island” no one metric can paint the entire performance picture. The urban legend is that a Disk Queue Length greater than 2 for any given period indicates an I/O bottleneck. I’ve seen some very gifted SQL Server experts present a wealth of information on Disk I/O tuning only to get hammered with questions on Disk Queue Length for twenty minutes following the presentation. Check out this discussion by I/O expert Linchi Shea to get a better understanding of how Disk Queue Length can be used with related metrics to provide a picture of how I/O throughput is performing.

Happy New Year!