Estimated row count vs actual row count
He wasn't particularly well versed in SQL, so a lot of his scripting uses unneeded case statements and joins against string operations.
I realize that there is a lot of that going on in this query, and i intend to address it.
This is only an issue when adding the filter against the fsalesacc. Without that filter, the query runs in about 2 seconds. With it, a little under 20 minutes.
My real quesion is, why is it that the estimated row count is so out of line if my statistics are updated and have little to no fragmentation on my indexes?
Also, is there a workaround that doesn involve using a temp table or a loopback openquery to force the query to ignore the estimated plan?