I have a simple query that runs successfully, but when I introduce a variable into the query, I am unable to save a view using that query. For example:
SELECT * FROM mytable WHERE color = 'red';
This query runs fine. Then:
DECLARE color STRING DEFAULT 'red';
SELECT * FROM mytable WHERE color = color;
This query also runs fine. Then in the BigQuery UI I click to "Save view", but I get an error saying Unexpected keyword DECLARE. Why is that?
As explained in the documentation:
BigQuery views are subject to the following limitations:
You cannot reference query parameters in views.
What you want to do is not allowed. A view is limited to a single SELECT statement.
Related
In BQ I have saved view that connected to Data Studio. I need to add a parameter field to this view and control it from Data Studio.
Adding a dropdown list doesn't work, there is some complex calculations in BQ, i'm not getting the result i expected.
How i tried. Query, for example:
select *
from `project.dataset.table`
I added query parameter like this:
select *
from `project.dataset.table`
where subject = #subject
Then in Data Studio I added parameter field. But i'm getting this error message:
BigQuery error: Parameters are not supported; failed to parse view
How can I add parameter and connect view to Data Studio?
Use custom queries:
Choose Custom Query in BigQuery connector in Data Studio
Add the field as a parameter
BigQuery + DataStudio does support Query Parameter (as introduced here https://blog.google/products/marketingplatform/analytics/introducing-bigquery-parameters-data-studio/).
However, BigQuery itself doesn't support using using query parameter inside view definition. For now, you will have to leave the filter outside of the view.
I am trying to do a call to Teradata with a list of views of which I want to know the tables.
So I built a loop in an etl tool to execute "SHOW QUALIFIED SELECT * FROM ..." on all of them.
However, this seems to be unsupported and the teradata documentation suggests this too (any form of SHOW is not supported in stored procedures).
Could you think of another way to get the underlying tables in a view?
thank you
Update: FYI SHOW SELECT * FROM ... is different from SHOW VIEW
in that it also shows -ALL- underlying tables involved, e.g. in case of views on views.
Alternate call for the SHOW VIEW:
select createText from dbc.tvm t1 join dbc.dbase t2 on (t1.databaseId=t2.databaseId)
where TVMName = '<your_view_name>'
and databaseNameI = '<your_db_name>'
;
I need to execute a simple INSERT INTO query on an old Access97 database.
I'm starting with a very short example - which doesn't work:
INSERT INTO [MY-TABLE]( [Field1] )
VALUES ( "blabla" )
MY-TABLE is the actual name of the table and Field1 is a String field.
I get the error:
Query input must contain at least one table or query
Because I need to insert literal value, I don't want to use a query here (i.e. a SELECT FROM)
Reading also the docs (https://msdn.microsoft.com/en-us/library/bb208861(v=office.12).aspx) I don't see where my SQL is wrong.
UPDATE
Here a couple of screen shot of the actual table and fields:
here the SQL code:
Anyway...
SOLVED!!
It works even with double quotes.
The problem was the push button I was using to check: using the "View" button leads to the error above. Instead I must use the "exclamation mark".
I need to execute the query using the "exlamation mark" button instead of the view one. This is because my query has not a result set to view - hence the error I saw.
By the way I confirm the syntax is accepted both with single or double quotes.
I'm reading sql code which has a line that looks like this:
SELECT INTO _user tag FROM login.user WHERE id = util.uuid_to_int(_user_id)::oid;
What exactly does this do? The usual way to use SELECT INTO requires specifying the columns to select after the SELECT token, e.g.
SELECT * INTO _my_new_table WHERE ...;
The database is postgresql.
This line must appear inside of a PL/pgSQL function. In that context the value from column tag is assigned to variable _user.
According to the documentation:
Tip: Note that this interpretation of SELECT with INTO is quite different from PostgreSQL's regular SELECT INTO command, wherein the INTO target is a newly created table.
and
The INTO clause can appear almost anywhere in the SQL command. Customarily it is written either just before or just after the list of select_expressions in a SELECT command, or at the end of the command for other command types. It is recommended that you follow this convention in case the PL/pgSQL parser becomes stricter in future versions.
I have to perform lexical analysis on the oracle query and separate the query to various parts (based on the clauses)in perl. For example,Consider :
Select deleteddate,deletedby from temptable where id = 10;
I need to print
select : deleteddate , deletedby
from : temptable
where : id = 10
I used this code snippet :
my $parser= SQL::Statement->new();
$parser->{PrinteError}=1;
my $query = SQL::Statement->new("select deleteddate,deletedby from temptable where id =10",$parser);
my #columns = $query->columns();
print $columns[0]->name();
Though this prints deleteddate, this fails when i give a subquery inside the select clause:
Select deleteddate,deletedby,(select 1+1 from dual) from temptable where id = 10;
Can you please point me in the correct direction.
Thanks.
It looks to be a limitation of that package; it seems to be a general purpose parser and not something that can understand advanced features like subqueries or Oracle-specific constructs like "from dual".
What are the constraints of your system? If python is an option it looks like this is a more fully-featured library:
http://code.google.com/p/python-sqlparse/
The other option would be to use the actual Oracle database, if that's an option. You would:
use the DBI and DBD::Oracle modules to create a connection to Oracle & get a database handle,
create a statement handle by calling prepare() on the database handle using your query,
execute the query (there may be an option in Oracle to execute in "test only" or "parse only" mode),
examine the statement handle (such as the NAMES_hash property) to get the column names.
Otherwise it seems the SQL::Statement module unfortunately just isn't up to the task...