I'm not sure what you mean,

Put it this way.

write this code:

DECLARE @tmp TABLE

(COL1 INT)

INSERT INTO @tmp

SELECT null UNION ALL

SELECT TOP 10 n FROM Tally UNION ALL

SELECT null UNION ALL

SELECT null...

ok but are you using the alias to reference the column ?

Eg.

SELECT

...

t1.ObjectId

FROM @mytable t1

INNER JOIN blah t2 ON t1.ObjectId = t2.objectID

...

hi again,

OK you need to alias your tables you can't fully qualify colums in a table variable.

You code should be like this.

IF (@NoPermCheck=0)

BEGIN

...

May I also just add that, changing from a temp table to a table variable may not give you a performance boost...

is this all the code?

I have a feeling that something is missing here?

you code section isn't 57 lines long?

Thanks

Chris

NOPE.

What is happening is it is ordering by

1,n

So all the value that are not null have 1 and then value as order by

so all the 1's come first then all...

why do they need all columns of all rows?

I can't think of an app that would display that much data on one page!?! or maybe I'm just a small fish...

well it depends what data types you working with.

SELECT 1/10 will always return 0 as 1 and 10 are both INT.

If they where decimals then they would return .something for...

Does your test created duplicates with the transactions in place?

Sorry my change to your insert won't work

You need to make the where clause on the insert a NOT EXISTS(SELECT id from mytable WHERE field1 = @field1)

etc

let me know if...

ooops.

Could you edit your post and put line returns in as the screen is now left-right scrollable.

Also have tried running that code after changing the insert statement to see what...

Hi Michael,

I do also think sometimes that people don't make enough effort to find the answers themselves.

Some questions about syntax and things can simple be found in BOL or by...

he he he

sorry for all the replies.

Another possible problem could this:

Because you checking for the duplicates in another proc and not on the insert statement.

There is a chance that a...

Ok thought of something else.

If any of the following values are inserted as null then you won't find a duplicate.

@Name ...

I'm sorry thats not a soution...

They are different fields I got confused sorry I'll keep looking