If you mock that up and post a packaged workbook I'll take a look.
This is not a bug per se, it's a combination of the order of operations, the STR() function returning different results depending on data source, and an inefficient calculation that triggered that cascade of effects.
In the extract, the var1 calculation was materialized by the extract using Microsoft JET. When JET does the STR(ISNULL([status])) evaluation, it returns 1 or 0, however the var1 calculation is expecting that combination of functions to return "t" or "f", so the var1 calc returnst only the user_type for every row. This would appear to be incorrect results. I set up an example of STR(ISNULL([status])) in the attached to show this.
In the extract, the duplicated var1 (copy) calc is evaluated in Tableau, where STR(ISNULL([status])) returns "t" or "f", so the var1 (copy) calc is evaluating those as written, and I'm assuming that's the correct results. That's the behavior that Shawn was seeing.
The ISNULL() function returns True or False and that can be evaluated in an IF statement, so a simpler version of the var1 variable would be:
IF (ISNULL([Status]) AND [user_type] =="Client") OR ISNULL([user_type]) THEN
That returns the same results in both the live connection and the extract, see the var jtd calculated field.
(How I knew too look for this is from past experience with the STR() function returning different results depending on the data source, when I saw that in the calc to evaluate a boolean I thought something might be up there).
Interesting, I hadn't considered the difference between Jet and T. Good to know. Thanks,