Peter,
>Yes Larry, there is an index, and yes I´m issuing a SET INDEX TO before updating. That´s ok I guess?

Yes this is OK.

>
>Also the transaction type = 2 and the batchupdatecount=100, I have no idea if that´s a good number, but setting it too high (>=200) produces an error, something about exceeded number of parameters.

The default is good.

>BTW, Bifrost? Very interresting choice for a company name!

Thanks. I didn't want something like LM (or Larry Miller) Consulting. I wanted an interesting name. Given that I have some nordic blood (great grandfather came over from Sweden) and I've always liked stories of Norse mythology, it seemed a natural fit.

>
>Michael,
>How does one avoid updating the PK if duplicate values are not allowed?
>
>And without a PK, won´t querying the DB later on be awfully slow?
>
>I guess, it´s pretty clear by now that I´m no SQL Server wizard, but please bear with me!
>

No you do want a PK for joins and the like with other tables. However, it may not be a good idea to make the PK clustered.

IMO, clustered indexes are great when used for queries that deal with ranges. The idea in SQL is to retrieve the fewest number of pages so if you deal alot with range queries, you want those records physically grouped together.

As Mike said, when you update a clustered index, SQL updates the physical order of the rows within the table. It also updates all non-clustered indexes to account for any changes that took place when the clustered index was modified. There is a lot of overhead in this process. I recommend changing the clustered nature of the PK and see if that helps performance.

HTH.