Conditions missing in Server Connect Database Query Builder

Wappler General Bugs
#1

======== TEMPLATE BUG FORM ========

Wappler Version : 4.2
Operating System : Windows
Server Model: PHP
Database Type: MySQL
Hosting Type: Reseller

Expected behavior

I should be able to see my conditions in the builder

Actual behavior

The conditions panel looks like this.

image
image2006×1185 117 KB

Here’s the code from the PHP file…

    "name": "unscheduled",
    "module": "dbconnector",
    "action": "select",
    "options": {
      "connection": "appData",
      "sql": {
        "type": "SELECT",
        "columns": [
          {
            "table": "view_tripbits",
            "column": "tripbit_id"
          },
          {
            "table": "view_tripbits",
            "column": "title"
          },
          {
            "table": "view_tripbits",
            "column": "bgcolor"
          }
        ],
        "table": {
          "name": "view_tripbits"
        },
        "joins": [],
        "wheres": {
          "condition": "AND",
          "rules": [
            {
              "id": "view_tripbits.trip_id",
              "field": "view_tripbits.trip_id",
              "type": "double",
              "operator": "equal",
              "value": "{{$_GET.trip_id}}",
              "data": {
                "table": "tbl_tripbits",
                "column": "trip_id",
                "type": "number"
              },
              "operation": "="
            },
            {
              "id": "view_tripbits.start",
              "field": "view_tripbits.start",
              "type": "datetime",
              "operator": "equal",
              "value": "0000-00-00 00:00:00",
              "data": {
                "table": "tbl_tripbits",
                "column": "start",
                "type": "datetime"
              },
              "operation": "="
            }
          ],
          "conditional": null,
          "valid": true
        },
        "query": "SELECT tripbit_id, title, bgcolor\nFROM view_tripbits\nWHERE trip_id = :P1 /* {{$_GET.trip_id}} */ AND start = '0000-00-00 00:00:00'",
        "params": [
          {
            "operator": "equal",
            "type": "expression",
            "name": ":P1",
            "value": "{{$_GET.trip_id}}"
          }
        ]
      }
    },
    "output": true,
    "meta": [
      {
        "type": "number",
        "name": "tripbit_id"
      },
      {
        "type": "text",
        "name": "title"
      },
      {
        "type": "text",
        "name": "bgcolor"
      }
    ],
    "outputType": "array"
  },

It appears to only be this server action, but other queries in the same server action have the same issue. I don’t believe this was the case until I upgraded today.

#2

I have seen this happen reliabaly when the table schema does not have the columns used in the where condition.
It could be that due to update, you schema has been lost.
You can just use the DB manager to refresh schema of DB, Tables & the specific tables in use.
You can also click the refresh icon in the query builder UI. But you will have to close (cancel) the popup for the where conditions to show up correctly.

Do not save the qurey builder when you see such missing condition, or the builder will remove them.

#3
#4

Thanks @sid - Unfortunately that didn’t help.

#5

Damn. Must be a new bug then.
Could you also try opening the SA in code view, and take a look at the conditions’ JSON part?
Maybe you’ll find some columns that don’t even exist in the DB? That could also be breaking things since you say that refrfeshing schema did not help.

#6

It’s weird. One other query in that Server action has the same issue, but the others are fine. All based off the same view which hasn’t changed. All the fields are there in the database. I even duplicated the server action and saved the original and it’s still the same. Didn’t overwrite the conditions as would be expected.

I’ve redone the conditions now and it’s all fine so definitely a bug.

1 Like
#7

8 posts were split to a new topic: Older Query with MS SQL and schema update

#8