Here is an agregated list of the 26-ideas that were submitted based on my request (thanks everyone).
I am using this information to put together a TechEd session. I thought I'd open this up to a vote - which 10 would you chose as the worst things developers are currently doing? Post the ten (using their identifying letters) that you'd like to see make the list.
A) You currently use the SysAdmin (sa) account to access your database in a production application.
Developers shouldn't be accessing their database using the SysAdmin (sa) account. This account has to many privelages and a malicious user can take advantage of this. For example, using a SQL injection attack a malicious user can access all the databases, or even worse, the dreaded xp_cmdshell extended stored procedure.
B) Not only do you use the SysAdmin account, but you never set a password for the SysAdmin account ("server=(local);database=myDB;uid=sa;pwd=;").
C) You use SELECT * FROM MyTable to populate a simple control, such as a TexBox.
Developers should never use SELECT * when all they need are a couple specific fields from the table. For example code shouldn't SELECT * from a table with more than two fields to load a DropDownList, especially when large data types are used in the table, such as BLOBs and Text.
D) You don't use "SET NOCOUNT ON" and "SET NOCOUNT OFF" when creating stored procedures where you don't need to know the number of rows affected (such as a SELECT * FROM MyTable"). By Using "SET NOCOUNT ON" and "SET NOCOUNT OFF" you will streamline your sproc and reduce the amount of unnecessary data moved between the db and your application.
E) You current have T-SQL DML code embedded in your application code instead of using stored procedures.
F) You don't use any caching and hit your SQL Server on every page request even though the data only changes n-times per day.
G) You pass user input to SQL Server without validating it, or checking for potentially malicious code.
H) You embed your stored procedures with business logic code.
I) You use lots of BLOBs in ADO.NET because its easier than in classic ADO.
J) You store your database connection string in the web.config file, unencrypted.
K) You have over normalized your database.
L) You have lookup tables for data that has only a few possibilities (i.e. Gender: Male/Female)
M) You added the Machine\ASPNET account to the Administrators role in SQL Server.
N) You prefix all of your stored procedures with "sp_".
When the prefix is 'sp_' SQL-Server first check the master database (http://www.sqlmag.com/Articles/Index.cfm?ArticleID=23011). New system sp's in future releases can have the same name
O) You create VARCHAR(1) columns, VarBinary for True/False columns, etc.
P) You have no error handling in your stored procedures
Q) You use SELECT DISTINCT instead of fine-tuning your joins/where clauses to get the desired results.
R) You don't take advantage of referential integrity, or worse yet, you don't set up relationships between tables when there clearly should be.
S) You don't take advantage of output parameters in stored procedures (i.e. return a whole row of data when you only care about 1 value).
T) You make multiple calls to SQL Server to get the necessary data, when you could have made 1 trip.
U) You don't use Profiler and Index Tuning to get the most out of your design.
V) You use @@Identity to return newly created field values from sprocs.
You should use IDENT_CURRENT or SCOPE_IDENTITY to obtain values created on a specific table or any table in the current scope.
See: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadonet/html/manidcrisis.asp
X) You use EXEC (@stmt) when you should use EXEC sp_executesql @stmt = @stmt
Y) You don't index your foreign key columns.
Z) You use a SELECT statement inside an IF statement.