3.6GB doesn't seem large at all, especially for an ERP solution.

Five minutes might be a little excessive, but I'd agree that you probably want to back it up a little...

In the simple recovery mode entries to the log are not recorded. So backing up the transaction log won't really work. As for file/filegroup backups I would assume...

Oh, and at the end, do an ALTER DATABASE mydb2 SET MULTI_USER...

I'd do something like this if you really don't care about killing all those connections:

BACKUP DATABASE mydb TO....

GO

ALTER DATABASE mydb2 SET SINGLE_USER WITH ROLLBACK IMMEDIATE;

GO

RESTORE DATABASE mydb2 FROM...

Ah, whoops, my bad... try this:

SELECT Instances.Name AS InstanceName,

Guilds.GuildId,

Guilds.Name AS GuildName,

Guilds.Faction AS Faction,

convert(char(10), Kills.Date, 101) AS Date,

Realms.RealmId,

Realms.Name AS RealmName,

Realms.Zone,

dbo.fn_IsRealmPublic(Realms.RealmId) AS PublicRealm

FROM Instances

INNER JOIN Kills ON Instances.EndBossId = Kills.BossId

INNER JOIN...

Change MAX() to MIN() in the script I gave you. Should do it.

Ah, I'd missed that...

From what it looks like you're wanting to find the details of the most recent kill of a boss monster, correct? Why not do this...

SELECT Instances.Name...

Also if you're seeing long-term table scans on the Kills table, you might consider creating an index on Date and then Name... might help.

Well, there could be a lot of things, frankly. You might start by viewing the execution plan to see what action is taking so much time to execute.

What I'd...

Assuming that phone number is a character data type...

UPDATE mytable

SET PhoneNumber = RIGHT(PhoneNumber, LEN(PhoneNumber) - 1)

WHERE LEFT(PhoneNumber, 1) = '1'

Sort of... Add filegroups with the other data files to the database. Then you have a couple of options. To move the physical data, you can rebuild...

SELECT *

FROM table

WHERE ( @customerID = (CertainValue) AND customerID = @customerID)

OR @customerID (CertainValue)

That should do ya...

Ninja's right... but going beyond that there are some other issues here:

When you check the existence of a temporary table using object_id(), you have to reference it in tempdb......

Or better yet use a DDL trigger on the CREATE/ALTER/DROP PROCEDURE statements. Query the EVENTDATA() function for UserName, LoginName, TSQLCommand information and relay that back to you or store...

If you're generating new key values, output the new key and the old key using the OUTPUT clause and use it to seed the address record.