Sometimes I want to find out how many rows are in each user table in a database. The following SQL helps me determine this.

select 'SELECT COUNT(*) AS ' +
'''' +
RTRIM ( name ) +
'''' +
' FROM ' +
RTRIM ( name )
from sysobjects where type = 'U'
order by name

If you have a dedicated database server and the partition with the MySQL database fills up (or starts getting low), you can move your MySQL databases to a different location.

Let’s say you want to move the database to /home/mysql

Sometimes, on a high-volume / high TPS database, I want to make sure I've made updates to ALL the recovers, and not leave some orphaned data out there. This usually occurs because someone has a locked record while they're making a change. So when I'm making updates to multiple records (remember, SQL is SET based, so it applies to all records that match a condition), I use a belt and suspenders approach.

Murphy walks among us. You know Murphy, the famous "optimist" who helps make every bad situations even worse? Well, after a disaster has occurred is not the time to figure out how and where you need to recover your data. Sure, we practice (ok, hopefully we practice!) recovering our database(s) from tape or disk. And during our testing we restore it into a test database or, if we’re lucky enough, into a test server. Great, but how does the application connect to the recovered database if we’ve run into a massive hardware (server) failure?

There are a variety of ways to determine which version of SQL Server you are running. While the @@version information will tell you the current version
SELECT @@version
SELECT LTRIM(RIGHT(LEFT(@@VERSION,38),9))

The following code will as well, and in a slightly different format:
SELECT 'SQL Server '