UpdateBuilder ToSQL handles # of params >= maxLookup

There was no need to check against i in the loop:

i < maxLookup could happen even if placeholderStartPos >= maxLookup, if the setClauses contained expressions with multiple parameters. So the condition was dangerous in general.
In the normal case (one parameter per iteration), this was breaking at the boundary because placeholderStartPos == i + 1 at the start of each iteration through the loop, so that when maxLookup == 100 and i == 99, then placeholderStartPos == 100, breaking on the use of equalsPlaceholderTab with index out of range.
The condition that previously was i >= maxLookup and now applies always for non-expressions does the right thing in all cases, as it guards against the actual value of placeholderStartPos.

mgutz / dat