Unfortunately I have no idea where the lock escalation happens. It happens somewhere in a set of about 30 to 40 stored procedures that do the import. They were coded by some of my colleagues.My task is to provide a workaround. Server version ist SQL Server 2000. I still do not understand why those locks are not cleared. Here´s what I do:DECLARE @Error INTDECLARE @ErrorMsg VARCHAR(255)DECLARE @oSQLServer INTEGERDECLARE @Source VARCHAR(255)DECLARE @Return INTEGERdeclare @dynsql nvarchar(3000)declare @oDatabase intdeclare @oQueryResults intdeclare @Length intdeclare @CurrentDB varchar(255)declare @SQL varchar(8000)-- Create the SQLServer objectEXEC @Error = sp_OACreate 'SQLDMO.SQLServer', @oSQLServer OUT -- Set the login process to use NT AuthenticationEXEC @Error = sp_OASetProperty @oSQLServer, 'LoginSecure', -1-- Connect to server using NT AuthenticationEXEC @Error = sp_OAMethod @oSQLServer, 'Connect', NULL, @@SERVERNAME-- Verify the connectionEXEC @Error = sp_OAMethod @oSQLServer, 'VerifyConnection', @Return OUTPUT-- Create Function with server objectselect @dynsql = N'CREATE Function MFF_Imp_DummyLockConnectionTest () RETURNS INT AS BEGIN RETURN ' + cast(@oSQLServer as varchar) + N' END'EXEC sp_executesql @dynsql-- Set the database object to be the current databaseSELECT @CurrentDB = DB_NAME()SELECT @CurrentDB = 'Databases("' + RTRIM(@CurrentDB) + '")'EXEC @Error = sp_OAGetProperty @oSQLServer, @CurrentDB, @oDatabase OUT --+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- Build the SQL stringSET @SQL = (Some statements that will result in some rowlocks after opening a transaction)'--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- Execute the SQL SET @Length = LEN(@SQL)SET @ErrorMsg = '' -- Must initialize the @ErrorMsg stringEXEC @Error = sp_OAMethod @oDatabase, 'ExecuteWithResultsAndMessages', @oQueryResults OUTPUT, @Length = @Length, @Command = @SQL , @Messages = @ErrorMsg OUTPUTEXEC @Error = sp_OADestroy @oDatabaseEXEC @Error = sp_OADestroy @oQueryResultsbegin tranSome real work here. If this code works the locks are cleared afterwards as the cleanup part executes. If the procedure crashes here the locks still are there...commit tran-- Get the connection objectSelect @oSQLServer = dbo.MFF_Imp_DummyLockConnectionTest()-- Set the database object to be the current databaseSELECT @CurrentDB = DB_NAME()SELECT @CurrentDB = 'Databases("' + RTRIM(@CurrentDB) + '")'EXEC @Error = sp_OAGetProperty @oSQLServer, @CurrentDB, @oDatabase OUT --+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- Build the SQL stringSET @SQL = 'Commit Transaction '--+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++-- Execute the SQL (this will NOT be rolled back)-- We could use ExecuteImmediate here, but it doesn't return a result-- and we found while debugging that you really NEED thatSET @Length = LEN(@SQL)SET @ErrorMsg = '' -- Must initialize the @ErrorMsg stringEXEC @Error = sp_OAMethod @oDatabase, 'ExecuteWithResultsAndMessages', @oQueryResults OUTPUT, @Length = @Length, @Command = @SQL , @Messages = @ErrorMsg OUTPUTEXEC @Error = sp_OADestroy @oDatabaseEXEC @Error = sp_OADestroy @oQueryResultsif exists (select * from sysobjects where id = object_id(N'dbo.MFF_Imp_DummyLockConnectionTest') and OBJECTPROPERTY(id, N'IsScalarFunction') = 1)drop function dbo.MFF_Imp_DummyLockConnectionTestAny ideas?Daniel