How to utilise {{data}} in a SQL Query?

App Building
#1

How do I format this so it resolves EXAMPLE_NUM ?

SELECT * FROM project.dataset.table_name_{{example_num.data.EXAMPLE_NUM}}

#2

Hey @Forde_Smith!

Basically, you're looking to have a dynamic table name? If so, I think your first step would be to disable prepared statements in the resource setup page. :slight_smile:

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 a resource with that setting enabled to help limit the surface area that you have to keep in mind SQL injection for.

#3

Hi @Victoria - so for the use case I raised here (dynamically setting a table name), disabling prepared statements works. However, it stops all? other uses of {{variables}} working in SQL statements (e.g. where ID = {{data.ID}} ). So it seems that this is not a fix.

#4

Hey @Forde_Smith! This should work actually :thinking: Is there anything I can do to try replicating your issue?

#5

Hi @victoria

Thanks for the post.

When I disable prepared statements to dynamically set the table name, all of the rest of my SQL queries break. I'll need to experiment further to see why or if I can get them working again.

#6

That's so odd :frowning:

I can step in to take a look if you'd like! The name of your app and/or query names would be helpful.

And in the meantime, you can create separate resources (one with prepared statements disabled and one with prepared statements enabled) to use in different queries. It's not a great workaround, but it's a workaround :sweat_smile: