Are you using the worklistcriteria object in the OpenWorklist call?

 There was a change moving from SP2a to SP4 where the filtering was moved to the SQL server backend.  Previously the filtering was done on the K2 server side.

 A couple of options that are common:

1. 
   
2. If you don't need to return process data from the OpenWorklist call, try setting the NoData property on the WorklistCriteria object to true.
   
3. Bypass the worklistcriteria object if possible.

Hi Jonny

Thanks for getting back to me.

Unfortunately we need process data so we can't use the NoData call, and I do need to use the worklistcriteria as I need to filter out what processes are being returned.

 Any other ideas?

Hmm, if you are locked in to use the worklistcriteria object and you also require data fields.  You could probably try:

1. 
   
2. Run the openworklist call without the worklistcriteria object but do the filtering in code on the web server.
   
3. Tune the process to make sure that any fields that are not needed on the client pages are marked to be loaded on demand (in the data fields properties).
   
4. Tuning your SQL server physical setup.  e.g. using filegroups, separating the DB data and transaction log files into separate LUNs on your SAN, etc.  Check with your SQL DBA for tips.
   
5. Run a SQL profile trace to capture your worklist query SQL statement and run it through the tuning wizard to see if it can improved by using indexes.

Other than that, you could probably stick with SP2a if that works fine unless you need any of the new features in SP3/4.  However, you would need to rollback your upgrade and this might not be possible in a live environment.

Great ideas, thanks very much.

I'll give it a try

Is there a way to extend the timeout threshold on K2 connection object or on SQL server side?

Smully, how many filtering criteria are you using?

The only timeout I can think of extending is on IIS for the connection timeout.

For the criteria I am using 3, one to get the right process folder, one to narrow it down to the correct set of procceses inside the folder and a sort field.

You think that makes a difference?

johnny:

Hmm, if you are locked in to use the worklistcriteria object and you also require data fields.  You could probably try:

1. 
   
2. Run the openworklist call without the worklistcriteria object but do the filtering in code on the web server.
   
3. Tune the process to make sure that any fields that are not needed on the client pages are marked to be loaded on demand (in the data fields properties).
   
4. Tuning your SQL server physical setup.  e.g. using filegroups, separating the DB data and transaction log files into separate LUNs on your SAN, etc.  Check with your SQL DBA for tips.
   
5. Run a SQL profile trace to capture your worklist query SQL statement and run it through the tuning wizard to see if it can improved by using indexes.

Great idea, tried this on our dev system (haven't gone live with it yet) and it's working so much faster. Turns out the _FieldOnDemand table has an unindexed ID column... setting an index on this really speeds things up. Found it using SQL tracing, then we just let SQL fine tune the table and happiness ensues.

 Thanks very much