Hi Thomas - as I was writing my last post, I noticed that Remi had already written almost exactly what I was typing - so he "beat me to it" ie...

Which fields need to be compared?  Just an ID field, or several?

Beat me to it Remi!

Check out SET TRANSACTION ISOLATION LEVEL in BOL and see whether that gives you what you want.

So does

select o.OfficeID, d.DeptID, s.SectionID

from offices o join depts d on o.OfficeID = d.OfficeID join Sections s on d.DeptID = s.DeptID

Give you the results you want to insert to table4?

Assuming that you want any NULLs to be summed as zeroes, use the isnull() function to get rid of the worrying error:

select client,productcode,modifiedlot,location,sku,count(*) ct,cast(sum(isnull(grosswgt,0)) as decimal(18,4)) grosswgt,

  cast(sum(isnull(netwgt,0)) as decimal(18,4))...

What is the relationship between the first three tables?  Insertion is performed through use of the INSERT statement, believe it or not

Here's an example:

INSERT...

Hey, it's not as easy as you might think.  Try this (untested):

update m1

set SettingValue = 'True'

from ModuleSettings m1

where exists (select m2.ModuleID from ModuleSettings m2 where m2.SettingName = 'GroupType' and m2.SettingValue...

Good tip

The top three lines appear to be duplicated for some reason - not that it matters.

To make this more manageable, I suggest that you implement this as a stored procedure...

Remember that such a trigger probably needs to deal with the insertion of multiple rows - a tasty bit of coding that might require a cursor.  Recommend that you stay...

How about putting the whole statement in one string and then executing that?  Something like this:

create procedure TestInputTable (@InputTable varchar(100))

as begin

 declare @strSQL varchar(8000)

 set @strSQL= 'select * into #TempTable from '...

Yeah, that works, good thinking.  Obviously if an index definition has changed, the 'check for existing' is necessary as you'd want to replace the one that's there currently.

When you debug a stored proc which contains statements that fire a trigger, you do not get to debug the statements in the trigger - even if they are executing...

You can script the indexes one at a time (yawn) in Query Analyser, without getting the tables scripted.  I can't see how you can do this in one step for...