DBCC DBREINDEX

Rebuilds one or more indexes for a table in the specified database. DBCC DBREINDEX rebuilds an index for a table or all indexes defined for a table....

Also index defrag only reorders the leaf-nodes of an index (as opposed to index rebuild which completely recreates it.)

Hence, on your dev server the higher-level nodes could have a different...

The reason why is that the optimizer is smart enough to lock different extents in the systems tables for each temp table (or real table if you want) so although...

That's not going to work very well for a multiple row update.

Perhaps something more like

Insert into <some tbl> (<field list> )

SELECT <fields>

FROM inserted inner join deleted ON inserted.<primary...

As written every time it runs it does one or more selects from inserted and 14 inserts

If  update(blz)

select * from inserted

INSERT INTO [eGecko3_Tr].[dbo].[Änderungen_Spender] (Spender_ID, [Name], Vorname, Telefon, [Straße], Land, PLZ,...

If I'm going to do an insert across linked servers, it looks like this

Insert into LocalDB.dbo.tbl (<fieldlist&gt

SELECT <fieldlist> FROM RemoteServer.RemoteDB.dbo.OtherTbl

Be very careful of select......

Greg. It's quite irrelevent where in the column order the primary key is. I assume that your primary key is clustered (since it's the default)

The data will be stored on...

Regarding the 27 million rows... No cross joins, no bad connections (local machine to local machine), Table we were pushing into had a clustered index. TempDB is free to grow,...

Select date, category, count(*) AS cnt from MyTable

Group By date,category

UNION ALL

Select date, 'Target' AS category, 30 AS Cnt from MyTable

Group By date

That's one solution. I'm sure there are others.

Try copying those 800000 records to another server without DTS. Select ... Into ... across a linked server is painful to say the least.

Also the 'school-of-hard-knocks code' can give problems...

This one will also work.

SELECT * FROM TableA LEFT JOIN TableB ON TableA.ID=TableB.ID

WHERE TableB.ID IS NULL.

Well you start by firing the DBA who let a developer make changes directly in production.

Code moves from dev to QA to Prod, not the other way around.

If you use DTS (which can be very, very fast in the right conditions) specify a query instead of a table and add the with (nolock) clause. That will ensure...

How did you copy the database from production?

Second the question of what exacly you did with the indexes.

How big is the table in question?

It is indeed acceptable for the execution plans to differ. On my production server...