why ? Faster wider pipes, better queries that don't return 1000 rows???

Note that data is returned in packets, packet size can help, even if you return a bit it still...

to be blunt the 2k tool is crap and likely to do more harm than good. I'd suggest using an eval of sql2005 and the tuning advisor which is much...

get a 64bit dual core server with at least 16gb of ram. Memory will offset most disk subsystem performance problems. make sure at least that o/s+ binaries, tran logs, data...

you need to profile to see if the delay is between client and server or in the proc execution first.

If the proc execution is the same then you need to...

From a best practice point of view you should never use select * - unless I guess you want the entire table, but even there it could lead to code...

It's a shame it writes to the registry, couldn't really use this in a controlled or production environment.. I slightly worry that this may prompt the unwary to start making...

you can read the job status from the job tables and use the appropriate stored procs to enable or disable them as required.

your hardware is probably fine, however for large updates/inserts it will always work better if you batch them.

If you can set the database to bulk logged or simple recovery this...

yeah most seem to miss out dbcc updateusage but it's quite important to run and I never found it did any harm. glad it resolved your problem.

it's really very easy .. here's an example for sql2k adding a table to transactional replication:-

--

-- add table to publication

--

exec dbo.sp_addarticle 'mypublication' ,@article='mytable',@source_table='mytable',@destination_table='mytable',

@force_invalidate_snapshot=1

go

--

-- refresh the subscription

--

exec dbo.sp_refreshsubscriptions  'mypublication'...

If you need to assign a variable to the database name you might just as well hardcode it avoid using dynamic sql.

select * from pubs.dbo.testrs

or

declare @string varchar(250),@db varchar(25)

set @db='pubs'

set @string=...

there's a number of reasons,  make sure you do a dbcc updateusage too.

So your shrink worked I assume, so if you rebuild all the indexes, stats and updateusage, it should...

Be careful when using a copy of a database beacuse you've lost the original hardware and environment which might be the problem. My guess is that when you try the...

I'd suggest your hardware is insufficient for your needs and if you're actually using a single disk you will be i/o bound without doubt!  You might want to consider turning...

Why do you feel the need to shrink your database - it will cause fragmentation and degrade performance. Leave your database at a size where it has working space to...