Hi Laszlo,

I'm assuming your service code is using the SourceCode.Workflow.Management API when calling GetWorklistItems().

First, double check to make sure the account making the call for the worklist has Admin rights to K2. If it does and you're still seeing SQL Server kick this error, I would suggest opening a ticket with Nintex support to see if they can help you dig deeper. 

Jason

Did it work previously and now it doesn't?

If you capture the SQL and execute it in SSMS, do you still get the error?

Hi David!

I think i found the problem. We use a filter before call GetWorklistItems to filter a special serial numbers and actions to the user.

This is the part of the code:

foreach (var item in serialNumbers)
{
var splitted = item.Split('_');
var procinstid = int.Parse(splitted[0]);
var activity = int.Parse(splitted[1]);

wCrit.AddRegularFilter(WorklistFields.ProcInstID, Comparison.Equals, procinstid, RegularFilter.FilterCondition.OR_OPEN);
wCrit.AddRegularFilter(WorklistFields.ActInstDestId, Comparison.Equals, activity, RegularFilter.FilterCondition.AND_CLOSE);
}

WorklistItems wlistitems = wms.GetWorklistItems(wCrit);

If the number of the serialNumbers is greater than 95 the error will occur

It has been a while since I have used this API.   It looks like you are maintaining a list of serial numbers assigned to a user.  Here are some ideas:

1. Tasks by their nature are assigned to a user or group.  Could you change the criteria to filter by user?

2.  You could filter the list as narrow as possible with simple criteria, then use something like LINQ to  filter the initial collection by process instance and activity destination instance.

Thanks for help, at first I'll create a new case to the support because it's seems very easy to fix the dynamic slq (change DECLARE @paramlist NVARCHAR(4000) to DECLARE @paramlist NVARCHAR(Max))