BigQuery gives "Missing whitespace" error when creating a Materialized View - google-bigquery

The error
When trying to create a Materialized View, I get the error Syntax error: Missing whitespace between literal and alias at [1:42]. The same error is not flagged in the FROM for any queries that I've run, so far. The issue seems to be the character after the numeric part of my (auto-generated) project ID.
Project ID changed to protect my real ID, but the format is the same
My code
CREATE MATERIALIZED VIEW my-project-1234a.firestore_export.viewTestBQ
AS SELECT name, SUM(clicks) AS sum_clicks
FROM my-project-1234a.firestore_export.TestBQ_raw_changelog
GROUP BY 1
What I've tried
Putting single quotes, double quotes and backticks around the Project ID
Putting single quotes, double quotes and backticks around the whole ${projectId}.${dataset}.${view_name} string

BigQuery uses special backlits when selecting an object. Consider the approach:
CREATE MATERIALIZED VIEW `my-project-1234a.firestore_export.viewTestBQ` AS
SELECT name, SUM(clicks) AS sum_clicks
FROM `my-project-1234a.firestore_export.TestBQ_raw_changelog`
GROUP BY 1
And if this doesn’t seem to work, also consider the following approach:
CREATE MATERIALIZED VIEW `my-project-a1234.firestore_export.viewTestBQ` AS
SELECT name, SUM(clicks) AS sum_clicks
FROM `my-project-a1234.firestore_export.TestBQ_raw_changelog`
GROUP BY 1
As you can see, the difference between my two recommendations is that, in your project, you will need to start with a letter followed by numbers instead of numbers followed by a letter.

Related

SQL keyword as column name [duplicate]

One of my columns is called from. I can't change the name because I didn't make it.
Am I allowed to do something like SELECT from FROM TableName or is there a special syntax to avoid the SQL Server being confused?
Wrap the column name in brackets like so, from becomes [from].
select [from] from table;
It is also possible to use the following (useful when querying multiple tables):
select table.[from] from table;
If it had been in PostgreSQL, use double quotes around the name, like:
select "from" from "table";
Note: Internally PostgreSQL automatically converts all unquoted commands and parameters to lower case. That have the effect that commands and identifiers aren't case sensitive. sEleCt * from tAblE; is interpreted as select * from table;. However, parameters inside double quotes are used as is, and therefore ARE case sensitive: select * from "table"; and select * from "Table"; gets the result from two different tables.
These are the two ways to do it:
Use back quote as here:
SELECT `from` FROM TableName
You can mention with table name as:
SELECT TableName.from FROM TableName
While you are doing it - alias it as something else (or better yet, use a view or an SP and deprecate the old direct access method).
SELECT [from] AS TransferFrom -- Or something else more suitable
FROM TableName
Your question seems to be well answered here, but I just want to add one more comment to this subject.
Those designing the database should be well aware of the reserved keywords and avoid using them. If you discover someone using it, inform them about it (in a polite way). The keyword here is reserved word.
More information:
"Reserved keywords should not be used
as object names. Databases upgraded
from earlier versions of SQL Server
may contain identifiers that include
words not reserved in the earlier
version, but that are reserved words
for the current version of SQL Server.
You can refer to the object by using
delimited identifiers until the name
can be changed."
http://msdn.microsoft.com/en-us/library/ms176027.aspx
and
"If your database does contain names
that match reserved keywords, you must
use delimited identifiers when you
refer to those objects. For more
information, see Identifiers (DMX)."
http://msdn.microsoft.com/en-us/library/ms132178.aspx
In Apache Drill, use backquotes:
select `from` from table;
If you ARE using SQL Server, you can just simply wrap the square brackets around the column or table name.
select [select]
from [table]
I have also faced this issue.
And the solution for this is to put [Column_Name] like this in the query.
string query= "Select [Name],[Email] from Person";
So it will work perfectly well.
Hi I work on Teradata systems that is completely ANSI compliant. Use double quotes " " to name such columns.
E.g. type is a SQL reserved keyword, and when used within quotes, type is treated as a user specified name.
See below code example:
CREATE TABLE alpha1
AS
(
SEL
product1
type_of_product AS "type"
FROM beta1
) WITH DATA
PRIMARY INDEX (product1)
--type is a SQL reserved keyword
TYPE
--see? now to retrieve the column you would use:
SEL "type" FROM alpha1
I ran in the same issue when trying to update a column which name was a keyword. The solution above didn't help me. I solved it out by simply specifying the name of the table like this:
UPDATE `survey`
SET survey.values='yes,no'
WHERE (question='Did you agree?')
The following will work perfectly:
SELECT DISTINCT table.from AS a FROM table
Some solid answers—but the most-upvoted one is parochial, only dealing with SQL Server. In summary:
If you have source control, the best solution is to stick to the rules, and avoid using reserved words. This list has been around for ages, and covers most of the peculiarities. One tip is that reserved words are rarely plural—so you're usually safe using plural names. Exceptions are DIAGNOSTICS, SCHEMAS, OCTETS, OFFSETS, OPTIONS, VALUES, PARAMETERS, PRIVILEGES and also verb-like words that also appear plural: OVERLAPS, READS, RETURNS, TRANSFORMS.
Many of us don't have the luxury of changing the field names. There, you'll need to know the details of the RDBM you're accessing:
For SQL Server use [square_braces] around the name. This works in an ODBC connection too.
For MySQL use `back_ticks`.
Postgres, Oracle and several other RDBMs will apparently allow "double_quotes" to be used.
Dotting the offending word onto the table name may also work.
You can put your column name in bracket like:
Select [from] from < ur_tablename>
Or
Put in a temprary table then use as you like.
Example:
Declare #temp_table table(temp_from varchar(max))
Insert into #temp_table
Select * from your_tablename
Here I just assume that your_tablename contains only one column (i.e. from).
In MySQL, alternatively to using back quotes (`), you can use the UI to alter column names. Right click the table > Alter table > Edit the column name that contains sql keyword > Commit.
select [from] from <table>
As a note, the above does not work in MySQL
Judging from the answers here and my own experience. The only acceptable answer, if you're planning on being portable is don't use SQL keywords for table, column, or other names.
All these answers work in the various databases but apparently a lot don't support the ANSI solution.
Simple solution
Lets say the column name is from ; So the column name in query can be referred by table alias
Select * from user u where u.from="US"
In Oracle SQL Developer, pl/sql you can do this with double quotes but if you use double quotes you must type the column names in upper case. For example, SELECT "FROM" FROM MY_TABLE

oracle sql - using double ampersand (&&) and double dot (..)

I'm new to Oracle SQL. I came across the following statement:
CREATE TABLE &&DATABASE_ONE..TABLE_ONE(...);
The statement above is trying to create a table. I'm not sure if I have correct understanding on .. and &&.
I have done some Googling, I found out this link that says double dot(..) will choose the default schema for the query.
DATABASE_ONE should be the schema name, and TABLE_ONE should be the table name.
I'm confused of using && in front of the database name. After Googling, I found out some posts say that && means "Oracle will prompt the user for a value and will create a permanent variable".
Could someone explain how && works in the statement above? Please correct me if I have any misunderstanding.
#Gary_W has covered the difference between a single and a double ampersand.
The double period is perhaps slightly less obvious. From the SQL*Plus documentation:
If you wish to append characters immediately after a substitution variable, use a period to separate the variable from the character.
If you had a single period:
&&DATABASE_ONE.TABLE_ONE
then that period would be treated as the terminator for the substituion variable name, and would be consumed in the process. Say the value you entered was 'HR'; the substitution would be:
old:select &&DATABASE_ONE.TABLE_ONE from dual
new:select HRTABLE_ONE from dual
select HRTABLE_ONE from dual
As you can see, there is now no period between the schema and table names, giving you a combined identifier which will not represent what you intended.
With the form you have:
&&DATABASE_ONE..TABLE_ONE
the second period is the 'normal' one that sits between those two elements; once the first has been consumed by the substitution, the second remains to fulfil that function:
old:select &&DATABASE_ONE..TABLE_ONE from dual
new:select HR.TABLE_ONE from dual
select HR.TABLE_ONE from dual
The double ampersand will prompt once and everywhere that variable is used it will use what was entered. If it had only one ampersand, you would get a prompt for every occurrence.
Try it yourself by creating a dummy script with multiple prompts for the same variable. First use single ampersands, note how it works then switch to double ampersands.
This link has a good explanation: https://www.oreilly.com/library/view/oracle-sqlplus-the/1565925785/ch04s02.html

Can't create a view - BigQuery

Getting:
Table IDs may contain letters, numbers, and underscores.
Trying to save the view as:
final-162619.final_project.GDELTblockchainVIEW
Using standard SQL for my query and it outputs a simple joined table just fine. It looks to be an issue with the hyphen and periods, is there a way to escape those? Standard [] brackets didn't seem to work
I don't believe saving the view as final-162619.final_project.GDELTblockchainVIEW is possible in BigQuery because of the fact you've got periods and hyphens in it.
The API also clearly states this:
You can quote your project id, dataset name, and table name with backticks. You have to quote them individually. For example:
SELECT `billing-address`
FROM `my-project`.`shopify-import`.`the-orders`
(If you have underscores instead of hyphens they don't need quoting.)

Select a field from table that contains parenthesis

I'm wondering if it's possible to have a fieldname with parenthesis () and be able to call it with a query. For example I have a field name called...
EnoughMoney(0)
Select EnoughMoney(0) from tbl1
When I select it in SSMS i get the following error....
'EnoughMoney' is not a recognized built-in function name.
The way you can escape names (of columns or of anything else) in SQL Server is by enclosing them in square brackets. Your query will work if you write it like
select [EnoughMoney(0)] from tbl1
As correctly stated by others, it's usually a good practice to avoid spaces and special characters in database objects' names, unless you are forced to, obviously.
Use Select [EnoughMoney(0)] from tbl1

Odd no such column error SQLite3

I'm only beginning to learn SQL with SQLite3 so this question probably has a clear answer, which I just can't think of. I have a table called Books, which has the columns: name, author and price. When I type e.g. select name, price from Books where author = "A"; in sqlite3, it works just fine. However, when I make a .sql file with the following:
SELECT name, price
FROM Books
WHERE author = "A";`
and read the file in the same database, it reads
'Error: near line 1: no such column: "A"'
Any ideas?
Edit: I have also tried the same with single quotes (i.e. 'A') but it still gives the same error:
Error: near line 1: no such column: 'A'
Double quotes "A" are used as identifiers; you want to use single quotes 'A' for string literals. See the documentation for more information.
SELECT name, price FROM Books WHERE author = 'A';
The reason it worked in the first example is probably due to this:
If a keyword in double quotes (ex: "key" or "glob") is used in a
context where it cannot be resolved to an identifier but where a
string literal is allowed, then the token is understood to be a string
literal instead of an identifier.
I found the solution. I was using Mac's TextEdit program to write the SQL queries and it uses so called "smart quotes", which are not recognized as quotes by SQL. So I just changed the smart quote-setting off and all is well.