Thank you for the link to http://support.microsoft.com/KB/158773 explaining that Update cursors need a primary key, and the solution to Msg 16929 - The cursor is READ ONLY, which ranks high on the search for this problem.

This is also the answer to your question the trigger inserted table does not have a primary key, so you either need to copy the data into a table with a primary key or use the primary key from the underlying table as per the comment.

WHERE CURRENT OF cur to WHERE incidentid = @incidentid? by GarethD

The design your team have come up has multiple layers of horror, and has sadly probably been implemented long ago.

Since it was likely a "higher management" decision to come up with more "user-friendly" identifier - a date string of the form YYYYDDDNNNN, where YYYY is the year, DDD the day of the year, and NNNN the sequence within the day, starting at 1.

It is also likely to be changed in future since DDD is equally unintuitive, and they are likely to move to YYYY-MM-DD-NNNN. The NNNN is guaranteed to not scale, if you have an automated input system it could well cascade over 10,000 events in a day and crash your system.

The simplest solution would be to use a calculated field for this key derived from the createddt (created data and time) and incidentid (the primary key).

You could have made the "user-friendly" identifier Date - incidentid. e.g. YYYY-MM-DD-NNNN..N where NNNN..N is the incidentid This would have no risk of exploding. Or just the last 4 digits of the incidentid.

And if implemented initially as YYYYDDDNNNN, the calculation could be changed according to the whims of "higher management" with out affecting the system.