When:

  • a filter is added to a view
  • the filter is based on multiple date fields
  • one or more of the fields comes from the base table (E.g. Node created date for a node view)
  • one or more of the fields doesn't come from the base table (E.g. field_data_field_xxxxxxx)

The SQL generated assigns the wrong table to the field that belongs to the base table. E.g. in the example above it will attempt to check field_data_field_xxxxxxx.created which doesn't exist.

This seems to be because of the code in date_views_filter_handler.inc not properly resetting $this->related_table_alias. (Note: The order in which the fields are processed will affect reproducing of this bug since it will only trigger if the base table field is processed after the non-base table field - not sure what controls that?)

Patch to follow.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

leewillis77’s picture

Status: Active » Needs review
FileSize
850 bytes

Patch attached. This resolves the error for me.

Status: Needs review » Needs work
leewillis77’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
leewillis77’s picture

https://drupal.org/node/2077839 has been marked as a duplicate of this.

leewillis77’s picture

As far as I can tell the test failures are nothing to do with this patch. Can anyone else confirm?

leewillis77’s picture

[Removed comment, the 8.x branch seems largely irrelevant at this point]

cafuego’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work
leewillis77’s picture

Hi - as far as I can see the failing tests are nothing to do with this page - they seem to relate directly to date migrations which aren't touched by this patch.

morbiD’s picture

Issue summary: View changes

The above patch seems to fix the problem for my particular use case ("Content: Last comment time" and "Content: Updated date" in the same date filter).

However, I should probably point out that the } else { syntax in the patch doesn't comply with Drupal coding standards which state: "The closing curly should be on a line by itself and indented to the same level as the opening statement."

  • cafuego committed 090d02e on 7.x-2.x authored by leewillis77
    Issue #2072679 by leewillis77: SQLSTATE[42S22] error and no results when...
cafuego’s picture

Version: 7.x-2.6 » 7.x-2.x-dev
Status: Needs work » Fixed

I've applied the patch and fixed the code style issue. Pushed to 7.x-2.x-dev.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.