error while updating task

Today we face a strange problem.
We are facing this error

“The workflow's parent item associated with this task is currently in the recycle bin, which prevents the task from being completed.”

We are totally confuse what this error want to say.

Below is the scenario when we are getting error.

We have a requirement where admin can reassign task to of a user to another user.
So we are assigning a task to another user by changing “assign to” field of tasklist item.

When we are calling item.update() (also tried systemupdate() and updateoverwriteversion() ) we are getting this error.

But we are not able to understand why this error is coming.
Then after spending 2-3 hours we are come to a conclusin.
we are getting this error because we are trying to update task which has attached with custom content type and that content type has been inherited by workflow task item.

Even though that task is not created by workflow but if task created with content type that is being inherited by workflow task item then you can not update it directly it should be updated by workflow only.

So in our case we change the content type from workflow task item to simple task itme so that will solve our problem. But we are still not able to understand the error massage.

Working with large list

Hi all,

Every time we start designing any project on sharepoint, we or I can say all, are having same problem.

Where to store the data in the sharepoint? (Which can be used as data table? in the language of dumb client who want to use sharepoint but don’t know why)

This is the million dollar question for starting any sharepoint project.

And billion dollar answer is none other than SharePoint Custom Lists.

And after deciding to go with the list another question will come about the taxonomy and structure of list.

You may also read so many article that more that 2000 item is hitting performance in the list. And that is true (that is what Microsoft says)

We found one of a very good document from Microsoft regarding the same Issue with title “Working with large lists” here is the link.


It really worth to read this article to decide architecture.

So we found one way to over come this situation.

Scenario: we are analysis SharePoint solution for one of the manufacturing plant.
And data is been stored in SharePoint list. For an example order list is containing a large number of data. So our first concern is how to implement this much data in one list.
One of the best solution we found is we created taxonomy for SharePoint list item. We decided to store order data in list with folder structure.

What we thought is that create a solution which will help to over come this 2k item problem.

First a folder is created for year like “2009” then month like “3” and then we are storing item in that folder. ( according to client they will not get orders more then 2k per month) other wise you keep segregating this with weeks, or days or may be hours according to your need.
So in our case if I’m adding an order today then my folder structure is
Order list/2009/3/my item

Note: we are storing/inserting item in the list programmatically and will post the same thing (how to do it programmatically?) asap

So this will solve our one problem.

And at the same time another problem is how to store other data or other related things like ….. history for an example. And each order is having multiple records in history.

So to over come this problem we user same structure with one more node.
Year/month/ordered/item in the list. and this date is form order created date not history created.

So we can store multiple items almost 2k item related to one particular order.
So our order history list we will have following structure.

Order History List/2009/3/OrderID#27/history item.
Again repeating the same that if history table updated in April even that structure will be the same as we are creating structure according to order.

So this way we can over come form SharePoint view limitation of 2ooo items.

There are a lot of other ways like creating subsite of Order (Main Item) and store related info in that subsite only. And many more are there according to our need and time.

But this is one of the way that we had done and working fine so we thought that better to share the same to every one so that we can get impact if some one had other idea for similar kind of implementation or some draw back or side effect of this implementation so that we can share the same with community. Please fill free to comment and share your idea regarding the same.

Handling State Machine Workflow – Part 2

Hi All,


I am back with state machine worklfow part 2.

Please refer Handling State Machine Workflow – Part 1 for previous reading.

Let's proceed with part2. Ok, As of now we have services attached to the WorkflowRuntime, its now time to start an instance of the workflow.

First thing we will do here is get the name of the workflow class and we have to start the workflow from code. When we start the workflow, we will get an instanceID of that.

First get the WorkflowInstance class object.

WorkflowInstance instance;

instance = workflowRuntime.CreateWorkflow(typeof(Workflow1));

here workflow1 is the class name of state machine workflow. Change it accordingly to your state machine workflow class name. This method is even common for sequential workflow as well.

And then finally call,

instance.Start();

If you now take out the StateMachineWorkflowInstance like this,

StateMachineWorkflowInstance objinstance =
new StateMachineWorkflowInstance(workflowRuntime, instance.InstanceId);

you will get an idea about the first state being in objinstance. You can see it from its CurrentStateName property.

now, here comes the interesting part. As i said in previous part that you need to preserve the instance id because later at any other page or form, you may want to take the state machine workflow to different state. So you need to take out the same instance and perform the next state on the same instance. So for that you need to save this instance so that even machine is shut down due to power failure or any other thing. Then also you have instance saved in the database. For this, the very important line is.

instance.Unload();

Once you do this, your instance will get preserved to the database as we have attached the persistence service to the workflowruntime. Thanks to this service we are able to save it in the database.

The moment you unload the instance, it will be unloaded and freed from memory and stored in database, so even your memory is also free now. It will not keep running this workflow.

See the data stored in the persistence database once you unload the instance. Single Row will get inserted with that instance GUID. I have many other workflow instance persisted.



I will later explain you how we can take out a existing workflow instance and move our state ahead of same instance.