Hi there,
I'm trying to select columns in an sql query based on a segment control component value like this:
SELECT {{segment.value}}. Unfortunately, it doesn't recognize the value as identifier but string. Adding '"' does not work. Can anyone please advise?
Thanks!
Hi, I also have a component and use its value in my SELECT statement like you do, and it works as expected. I have to add '' for the query to recognize it as a string.
Can you maybe give more detail what your segment component's possible values are?
Hi @lazymaplekoi, Thanks for your reply!
I'm trying to simply select a column from a table with this snippet:
The button should allow me to either select only 'partner_id' or 'partner_id' and 'type'.
I tried it with the following value:
But all im getting is this:
I also tried normal " " and ' " ' + ... in the sql query but i can't get it to work.
Thank you very much for your support!
Hey, no worries!
I see -- the possible values for Distinguish are already string types, so what happens when you plug it in the query is like:
SELECT 'partner_id' ...
Maybe you can try removing the '' in the button values. Just partner_id, so {{Distinguish.value}} will be replaced with partner_id, and not 'partner_id'. 
Good Morning!
I already tried that and just tested it again, unfortunately i receive the same outcome. It seems like I can't get rid of the String format. Do you have any other ideas? 
Hmm, can you try manually getting rid of the quotes? like {{Distinguish.value.replace('\'', '')}} 
Nice try but still not working
It's spelled correctly and has no quotation marks. I was wondering if there is some sort of "as Type Identifier"?
Do you have any thoughts on that?
Does anyone else have any advice? I'm trying to select columns in an sql query based on a segment control component value like this:
SELECT {{segment.value}}.
However, i keep running into the same issue of the query not recognizing the input as identifier.
Hi there!
This looks like a prepared statements issue. When you have a dynamic table name or column name
If you run the query with the default settings on the database resource (prepared statements enabled), you get the wrong results:
If you go to the resource settings - as an admin in your org - you can disable the prepared statements setting:
Allowing the query to work:
There's some things to keep in mind here though --
By default, all of our SQL queries are converted to prepared statements to prevent SQL injection, meaning that table/database names and SQL functions aren't able to be defined using a string created dynamically. The main reason we currently convert all statements into prepared statements, is so that users can't enter malicious syntax (like DROP TABLE) into the variable fields.
You can disable this setting in the resource setup, but keep in mind the potential of submitting dangerous SQL through any of the variables referenced in a query.
Disabling prepared statements can also break other existing queries. If that's something you'd like to explore, I often recommend setting up another copy of the resource with that setting enabled to help limit the surface area that you have to keep in mind SQL injection for.
This worked, thanks!