As you might gather, I'm working at a state agency this week- making a trainer's salary for a consultant's work *ahem*. That's another rant. The code I'm going through is pretty much a tutorial on what not to do. To be fair, the people I'm working with don't know anything about programming in a modern context. One of them has just gradually been hacked up the historical lineage of computer languages by trial and error, and the other was an HTML/JavaScript developer (if such a title applies). Now they're trying to do ASP.NET (and they've got ashitload of classic ASP).
Thing not-to-do 1: take strings from the user and append them to a SQL query with no validation whatsoever. This creates a vulnerability to a class of attack known as a SQL injection. Essentially, without all that much effort, a malicious user could 0wn your database. Or at least, own whatever the account used to connect to the database has permission to do.
Which brings us to thing not-to-do 2: your web application shouldn't connect to your database using administrator privileges. No. Under no circumstances! Don't even think about it! Of course, it should be trivial to migrate your code to log in under a different account, unless of course...
Thing not-to-do 3: don't use "short" table references. Always, always use at least the two part name for every table: "owner"."table". For example, if all of your tables are owned by "joebob", and you need to query the "sales" table, the name is "joebob"."sales", not "sales". If, for some reason you need to have your web app run with credentials other than "joebob", you'll get a crapload of errors for not supplying the full name of all of your objects. So, for example, you log in as "admin", and all the tables are owned by "admin". When a plucky consultant comes in to change the app over so that it can login as "limited-web-user", instead of "admin" (which is retarted) that plucky consultant doesn't want to have to create several hundred public synonyms so that your crappy legacy code still works.
Thing not-to-do 4: don't install a server without checking what hardware it has first. This way, when you complain that the web server is slow, the consultant doesn't point out that it's because it only has 512 megs of ram in it.