Lisa Nicholls
If you are using SP2 then I take back what I said about your needing to patch! I had a braino about this... I apologize, it's right in front of me, too...
If your "freak" is still there in SP2, then they put it back in without fixing the underlying performance issues, I guess. Which they have said is the reason they took it out in the first place.
Brian W's blog (https://blogs.msdn.com/bwelcker/) does have an interesting workaround with an internal param, which you might be able to use with a slight adaptaption, though, if you really must have huge param lists but need to set a safety threshhold. Here is how I imagine this working for you:
- Change the prompt to be "Over <N> items selected will be ignored" where you set <N> to something you think is reasonable
- Have a hidden param where you store <N> for code reference
- Build the SQL yourself instead of using the internal IN list (I just finished explaining this in another thread, so let me know if you don't already know how to do this) so that you eliminate this part of your WHERE clause or, if sending to a sproc, send this param as NULL if the number of items is > <N>.
This is, in fact, what I thought they would be doing as ancillary work when they made the change in SP1. It is what I would have done, if I had discovered that the thing was unsafe -- taking out Select All didn't really solve the underlying issue. I would have set some sort of a threshold beyond which the LOV would be ignored, published it, and treated it as a necessary fix. I imagine they are looking into doing something like this, post SP2, where they make <N> tunable, but I would have expected them to do it without the tunability right away.
>L<