Taxonomy Exposed Filters with AND/OR = SQLSTATE[42000]

This might be fixed in the meantime.

Therefore please update to the real latest version . It works fine here, see screenshot

Thanks for testing.

This patch fixes the issue for me. Please test it.

Okay so this still needs work...

Just my 2cents: OH TAXONOMY.

Thanks for testing.
Okay commited the patch which fixed the errors,
but there are still additional bugs reported in #4

I've hit a similar problem as the error.png screenshot shown in #4, under very similar conditions (though not exactly the same).

The attached patch fixes it for me. The full context is this:

    // Shorten some variables:
    $field = $this->get_field();
    $options = $this->handler->options;
    $operator = $this->handler->operator;
    $formula = !empty($this->formula);
    $value = $this->handler->value;
    if (empty($options['group'])) {
      $options['group'] = 0;
    }
    else {
      $value = $this->handler->value;
      $operator = 'IN';
    }

The "else" statement (which the attached patch removes) is what seems problematic:
(1) Setting $value is unnecessary since it was already set above.
(2) Setting $operator to 'IN' overrides the actual operator, and therefore bypasses code below this that checks, e.g., for cases where $operator is 'or' and runs specific logic based on that.

Does that makes sense?

The change was part of http://drupal.org/node/1023794 and the patch was applied totally false.
So here is a change with some additional cleanup on top: change $this-handler->value to $value everywhere.

This code is really ugly.
Note: Before commit this someone would have to look at the d6 version and see how it's there.

     elseif ($operator == 'or' && empty($options['reduce_duplicates'])) {
-      if (count($this->handler->value) > 1) {
-        $value = $this->handler->value;
+      if (count($value) > 1) {
         $operator = 'IN';
       }
       else {
-        $value = is_array($this->handler->value) ? array_pop($this->handler->value) : $this->handler->value;
+        $value = is_array($value) ? array_pop($value) : $value;
         $operator = '=';
       }
       $add_condition = FALSE;
     }
+    else {
+      $operator = 'IN';
+    }

The last part of the patch doesn't look right to me on a first glance... Because what happens if $operator starts off as 'or' and $options['reduce_duplicates'] is TRUE?

Then, this code will wind up switching the 'or' to 'IN'. But further down, the code does this:

$clause = $operator == 'or' ? db_or() : db_and();

so the end result will be that we started off with 'or' but wind up using db_and() in the query. I'm guessing that's wrong?

Note: Before commit this someone would have to look at the d6 version and see how it's there.

Here's a handy link: http://drupalcode.org/project/views.git/blob/refs/heads/6.x-3.x:/include...

I think it's consistent with not having to force the operator to 'IN' in D7, but I haven't studied it closely enough to be sure.

You are right.

This previous issue was basically just a 100% wrong commit.
The initial bug of the other issue was fixed with #955464: Missing join: 'taxonomy_term_data' creating a Glossary view based on taxonomy

So it's safe and just apply the patch in #8. Commited to 7.x

Here is a cleanup for the variable names and some documentation.

I didn't actually test it, but that followup patch certainly looks good to me...

Commited to 7.x
Thanks for the quick look up.