You really have given minimum infornation here. No join conditions, no where clauses or column names, no execution plans, no tables or table details. Sorry we can't help with some...

I recommend you do a little reading in Books On Line, or Google this as there are a lot of examples on how to do this.

Cheers

Leo

You don't need to worry about TempDB, it will grow as it needs to.

Carl's solution is also a good one if you have space on another disk, AND if this...

If TempDB or any other logs are on the same drive I would shrink those before I did anything else. SQL is pretty smart and if there is space on...

Have you checked what the inital size of the database file was when it was created? SQL doesn't shrink a database smaller than the initial create size. Sof the db...

Run sp_help_revlogin stored proc on the original server. This will create a script to recreate all logins with their password hashs.

If you don't have it you canget it here:

http://support.microsoft.com/kb/918992

Yo need...

onurcivi (8/31/2010)

---

..declare @tempDeposits table

(

DepositEntryId int,

DepositId uniqueidentifier,

ItemCount int

)

insert into @tempDeposits (DepositEntryId, DepositId, ItemCount)

select DepositEntryId, DepositId, ItemCount from Deposits

where --- insert business rules conditions here, not having any problems with this select...

zombi (8/31/2010)

---

Hi,

I am getting the following error when i run the above script.

Msg 451, Level 16, State 1, Line 1

Cannot resolve collation conflict for column 1 in SELECT statement.

Please advise....

It's been a while since I ran this, but it's one I wrote some time back for SQL 2005.

select 'GRANT ' + permission_name + ' on ' + o.name...

Lock Pages in Memory is a 64...

This is another of those "every dba has his own thoughts" issues.

You didn't say why the N/W team want to go with VMs, and this is critical. If they...

Three issues:

1) Never use SELECT COUNT(*)...

Besides being lazy coding, SQL assumes you actually want to count all the columns. Since you only actually need DepositEntryId rather use SELECT COUNT(DepositEntryId)...

By puting the conversion from i.object_id to table name, you are forcing the query paser to bypass indexes on the table and do a cluster index scan...

This doesn't sound like good practice. For the SQL Server Stored proc to be able to save the file onto the calling server's hard drive, it needs write permission on...

SQL is creating a parallel query, and this is independent of the size of the table. Without seeing the query and schema details etc. it's impossible to analyze much more...