I've spent a lot of time recently fixing bugs caused by a prior database dev who didn't actually understand SQL as well as he thought.

For example, an insert that had to go into two tables, where the first table holds part of the data and generates an ID value, and the second table needs that ID to FK back to the first one, and holds a different portion of the data. (Oddly enough, these tables were built to have a 1:1 relationship, and all columns were mandatory in both tables, so it could/should have been one table in the first place, but that's a different story.)

The way he implemented getting the ID value from the first table was selecting the Max() value for the ID where the e-mail address matched the input value for that column. Not Scope_Identity, not an Output clause (despite being in SQL 2005 from inception on this database), selecting the Max(ID) where Email = @Email. He never anticipated the fact that not every entry would have an e-mail address, and thus the parameter would be NULL, and would not assign a value. So, in cases where there was no e-mail address provided, NOTHING would be inserted into the second table. No error message for a failed insert, no alerts to the affected department personnel, just a completely silent failure to insert into the second table.

Thousands of rows of data, important to multiple departments, rendered useless over a period of 3 years, because he didn't know about Scope_Identity and related methods.

There was another, similar bug, again caused by ignorance of T-SQL, that was intermittently inverting the legal opt-in/out options on various things. No way to tell how many records are wrong, but it's probably again in the thousands.

Another one lost an indeterminate number of records of people requesting information from the company. Based on the way it was written, it could have lost only a few, or it could have lost 10s of thousands, and we'll never know, because the data was never inserted anywhere, it just went from the web app to nowhere at all, depending on some of the input values. Again, basics of SQL (in this case, ANSI and T-SQL rules were violated) would have prevented the data loss.

So, that's the kind of bug I'm dealing with right now.