Sometimes users get un-mapped from the server to database login after a database restore.
Here is the command to fix it:
EXEC sp_change_users_login ‘Auto_Fix’, ‘SRSUser’
Today I had an interesting issue with my WF3.5 SharePoint workflow.
A user was attempting to action a SharePoint workflow task and was given the error:
This task is currently locked by a running workflow and cannot be edited.
I have seen this error a small number of times (5-10) amongst the 1000’s of workflow instances that have passed through my production system.
I am always very careful with quiescing and always release a new workflow version the correct was using workflow.xml, feature.xml and stsadm.
There was a time a few weeks ago when we had to do an emergency bug fix as some of my business logic was not functioning as expected.
I know that I can never change an activity in my workflow without quiescing otherwise the serialization and deserialization (dyhydrate / re-hydrate) from the persistence store gets confused and hence an error like this occurs.
The funny thing is, I only changed code in a utility class and only the code inside an existing method (ie…method definition was not changed) so I thought that there was no need for quiescing. (no core workflow code was altered).
Anyway,just writing here incase anyone has an opinion on this.
From now on I will quiesce no matter what the emergency is!!