Skip to end of banner
Go to start of banner

Pass category object variables into a free hand SQL query

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

Firstly, and stating the obvious - but make sure that you really really need to use free-hand SQL in your chart.

OK - so your sticking with writing free hand SQL. The good news is that you can still reference [[VARIBALES]] and {{Object}} selections in the SQL.

image-20240926-121144.png

Use a [[VARIABLE]]

You can reference a [[VARIABLE]] anywhere in your SQL. You need to decide whether you need to use '' quotes , i.e. dates / strings, or no quotes if it is a number.

So I want to limit sales in free hand sql based on sales dates.

image-20240926-121705.png

In the edit chart screen as above - you will see your [[VARIABLE]] placeholder. However, if you save the chart and view the SQL in situ then you will see how the final SQL replacement looks, and exactly what has been executed on the DB.

image-20240926-121922.png

[[VARIABLE]] replacement can take place in any part of the query.

{{Object}} replacement in SQL.

In my Example I now add three category objects.

image-20240926-122122.png

You will notice that these do not apply to your free hand SQL elements. Are you still sure you want to use Free Hand SQL??.

The good news is though, that as with [[VARIABLES]] we can apply in the SQL itself.

So if I want region to apply I do the following;

image-20240926-122411.png

If I look at the executed SQL I will see it is changed when I change the drop list value.

image-20240926-122511.png

This is Good - but I get a problem if nothing is selected in the droplist.

When -All- is selected in the droplist then the {{object}} reference is not replaced in the SQL.

image-20240926-122712.png

Fixing All selections

I can fix the problem above by introducing an OR clause. This is how I do this, others may have other strategies for this.

image-20240926-122922.png

When All is selected the generated SQL looks like

image-20240926-123009.png

So now the OR part of the query is enacted when All is selected and I see all regions.

Wow that’s complicated - Yes it is / are you still sure you want to use free hand SQL? Pi handles all of this very elegantly for you when you don’t use free hand SQL.

Multi-picker

The {{object}} solution above is fine for the above but when you use a Multipicker you will see a list seperated by ::::

image-20240926-123754.png

But you’ll get no data because the SQL becomes.

image-20240926-123726.png

Now you may need to google your DB’s sql syntax here - as it could be different to my (MySQL) solution here.

image-20240926-124057.png

Then the SQL resolves to

image-20240926-124146.png

I can combine this with a element to cope when the user makes no selection.

SELECT
sum(nr_sales.QUANTITY) AS Y0,
nr_sales.PAYMENT_METHOD AS X0
FROM
retail.nr_sales nr_sales
JOIN retail.nr_stores nr_stores ON nr_sales.STORE_ID = nr_stores.STORE_ID
WHERE
(FIND_IN_SET(nr_stores.STORE_MANAGER , REPLACE('{{Store Manager}}', '::::', ',')) OR '{{Store Manager}}' LIKE '%{Store Manager}}')
GROUP BY
nr_sales.PAYMENT_METHOD
ORDER BY
nr_sales.PAYMENT_METHOD

In your db - you can find your syntax from the web / your favourite LLM

i.e.

image-20240926-124557.png

Handling a Between (Dates)

There are two values in a date range

You can find them by select the {{object[0]}} and {{object[1]}}

So Our SQL becomes

image-20240926-124822.png

When executed it will look like

image-20240926-125046.png

Note that the date is in a strange format - this is what the browser returns! - so we need to decode our date.

(DATE_FORMAT(nr_sales.SALE_DATE, '%d %M %Y') BETWEEN '{{Sale Date[0]}}' AND '{{Sale Date[1]}}')

NOTE: some browsers return Sep (September) as Sept. So everything is 3 chars except Sept.

So you may even need to

(DATE_FORMAT(nr_sales.SALE_DATE, '%d %M %Y')

BETWEEN REPLACE('{{Sale Date[0]}}','Sept','Sep') AND REPLACE('{{Sale Date[1]}}'),'Sept','Sep')

Wow that’s complicated - Yes it is / are you still sure you want to use free hand SQL? Pi handles all of this very elegantly for you when you don’t use free hand SQL.

FREE HAND SQL SHOULD BE A LAST RESORT

  • No labels