ah. I think you want the behavior that setting your transaction isolation level to SERIALIZABLE will provide. With the transaction isolation level set to SERIALIZABLE, SQL Server will maintain a range lock on the rows that are locked by the SELECT query until the transaction is committed. BUT this will affect your concurrency.

-Mike

>Hi Michael,
>
>probably I want to make what MSQL cannot make.
>
>However:
>
>my demand is the contrary:
>
>a SELECT must block commandos INSERT made on other sessions, only for commandos INSERT who contain a value used in the WHERE of the SELECT.
>
>Example:
>

>--SESSION 1
>DECLARE @rowsType1 TINYINT
>SET @rowsType1=1
>-- time = tStart
>SELECT MAX(field1) FROM myTable WITH(HOLDLOCK) WHERE field2=@rowsType1
>-- i want MAX(field1) not change for @rowsType1 rows group.
>.....
>COMMIT
>-- time = tEnd
>
>--SESSION 2
>-- time : t with tStart<t<tEnd
>INSERT INTO myTable (field1,field2) VALUES(34,2)
>-- this can insert without lock
>
>--SESSION 3
>-- time : t with tStart<t<tEnd
>INSERT INTO myTable (field1,field2) VALUES(34,1)
>-- this is locked until t>tEnd
>

>
>I declare index for field1 and field2, but INSERT on SESSION 2 is locked.
>
>If you want, i build a example for you to test on MS QUERY.
>
>Fabio