I have table named References in SQLite, so I can't target it, it seems. SQLite studio I use to edit databases throws an error.
Is there a way to escape database name?
The query is:
UPDATE References
SET DateTimeLastEdited = datetime('now', 'localtime')
WHERE NewsItemID = old.NewsItemID;
(This is part of the trigger I am making.)
You can escape table names with double quotes:
UPDATE "References" SET DateTimeLastEdited = datetime('now', 'localtime') WHERE NewsItemID = old.NewsItemID;
Depending on what you want to escape, you need to use different delimiters:
If you want to use a keyword as a name, you need to quote it. There
are four ways of quoting keywords in SQLite:
'keyword' A keyword in single quotes is a string literal.
"keyword" A keyword in double-quotes is an identifier.
[keyword] A
keyword enclosed in square brackets is an identifier. This is not
standard SQL. This quoting mechanism is used by MS Access and SQL
Server and is included in SQLite for compatibility.
`keyword` A
keyword enclosed in grave accents (ASCII code 96) is an identifier.
This is not standard SQL. This quoting mechanism is used by MySQL and
is included in SQLite for compatibility.
From SQLite documentation
Related
This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I'm trying to execute a simple MySQL query as below:
INSERT INTO user_details (username, location, key)
VALUES ('Tim', 'Florida', 42)
But I'm getting the following error:
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'key) VALUES ('Tim', 'Florida', 42)' at line 1
How can I fix the issue?
The Problem
In MySQL, certain words like SELECT, INSERT, DELETE etc. are reserved words. Since they have a special meaning, MySQL treats it as a syntax error whenever you use them as a table name, column name, or other kind of identifier - unless you surround the identifier with backticks.
As noted in the official docs, in section 10.2 Schema Object Names (emphasis added):
Certain objects within MySQL, including database, table, index, column, alias, view, stored procedure, partition, tablespace, and other object names are known as identifiers.
...
If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it.
...
The identifier quote character is the backtick ("`"):
A complete list of keywords and reserved words can be found in section 10.3 Keywords and Reserved Words. In that page, words followed by "(R)" are reserved words. Some reserved words are listed below, including many that tend to cause this issue.
ADD
AND
BEFORE
BY
CALL
CASE
CONDITION
DELETE
DESC
DESCRIBE
FROM
GROUP
IN
INDEX
INSERT
INTERVAL
IS
KEY
LIKE
LIMIT
LONG
MATCH
NOT
OPTION
OR
ORDER
PARTITION
RANK
REFERENCES
SELECT
TABLE
TO
UPDATE
WHERE
The Solution
You have two options.
1. Don't use reserved words as identifiers
The simplest solution is simply to avoid using reserved words as identifiers. You can probably find another reasonable name for your column that is not a reserved word.
Doing this has a couple of advantages:
It eliminates the possibility that you or another developer using your database will accidentally write a syntax error due to forgetting - or not knowing - that a particular identifier is a reserved word. There are many reserved words in MySQL and most developers are unlikely to know all of them. By not using these words in the first place, you avoid leaving traps for yourself or future developers.
The means of quoting identifiers differs between SQL dialects. While MySQL uses backticks for quoting identifiers by default, ANSI-compliant SQL (and indeed MySQL in ANSI SQL mode, as noted here) uses double quotes for quoting identifiers. As such, queries that quote identifiers with backticks are less easily portable to other SQL dialects.
Purely for the sake of reducing the risk of future mistakes, this is usually a wiser course of action than backtick-quoting the identifier.
2. Use backticks
If renaming the table or column isn't possible, wrap the offending identifier in backticks (`) as described in the earlier quote from 10.2 Schema Object Names.
An example to demonstrate the usage (taken from 10.3 Keywords and Reserved Words):
mysql> CREATE TABLE interval (begin INT, end INT);
ERROR 1064 (42000): You have an error in your SQL syntax.
near 'interval (begin INT, end INT)'
mysql> CREATE TABLE `interval` (begin INT, end INT);
Query OK, 0 rows affected (0.01 sec)
Similarly, the query from the question can be fixed by wrapping the keyword key in backticks, as shown below:
INSERT INTO user_details (username, location, `key`)
VALUES ('Tim', 'Florida', 42)"; ^ ^
Do any SQL databases have case-sensitive naming for field names?
What I mean is, in Java you can have two variables ...
String fieldname = "a";
String fieldName = "b";
Are there any SQL databases support that so ...
SELECT fieldname, fieldName FROM MY_TABLE;
... would return two different columns?
I'm asking because I'm building a database utility that has to work for MySQL, H2, PostgreSQL, Oracle, and SQL Server, so I need to know how they all work for a bit of code I'm writing.
In most databases (and in all those you tagged), an unquoted identifier is case-insensitive. Meaning that fieldname and fieldName are the same thing: the database folds them into the default case, which makes them equivalent.
In most databases, you can make an identifier case-sensitive by quoting it. The quoting character varies across databases. In standard SQL, you use double quotes. So "fieldname" and "fieldName" are two different things. Oracle and Postgres follow that standard. SQL Server wants square brackets ([]); MySQL wants backticks.
In a nutshell: in SQL, I would not recommend using case-sensitive identifiers. This makes things more complicated for no value added. In my opinion, snake case style is your best pick in SQL, because upper/lower case are meaningless.
By the SQL standard, SQL identifiers are case-insensitive. So, without escape characters, these refer to the same column:
select fieldname, fieldName
However, you can escape the names and they become distinguishable. The standard SQL escape character is ":
select "fieldname", "fieldName"
But some databases don't support this and have their own.
In Oracle, you can certainly have case-sensitive column names, they just need to be quoted. So this query would return data from three separate columns
SELECT "columnName", "ColumnName", columnName
FROM table
In SQL Server, you can have case-sensitive columns but they need to be enclosed in brackets, i.e.
SELECT [ColumnName], [columnName], [columnname]
FROM table
I am trying to do a query in a SQLite database equivalent to this:
SELECT act_unit FROM processes WHERE process='processname'
but using the keyword values, so I can specify the name, which is stored in a variable (I am actually running the query in a Jupyter notebook). I've used successfully the keyword values in insert statements, but I do not know how to do it here. I tried several combinations like this one
SELECT act_unit from processes WHERE process=values,('processname')
but I can't figure out how to do it properly.
From the SQLite documentation: https://www.sqlite.org/lang_keywords.html
It would be SELECT act_unit from processes WHERE process="values",('processname')
If you want to use a keyword as a name, you need to quote it. There
are four ways of quoting keywords in SQLite:
'keyword' A keyword in single quotes is a string literal.
"keyword" A keyword in double-quotes is an identifier.
[keyword] A
keyword enclosed in square brackets is an identifier. This is not
standard SQL. This quoting mechanism is used by MS Access and SQL
Server and is included in SQLite for compatibility.
keyword A
keyword enclosed in grave accents (ASCII code 96) is an identifier.
This is not standard SQL. This quoting mechanism is used by MySQL and
is included in SQLite for compatibility.
How to turn off forced upper-case mode for table and column names in HSQL?
<artifactId>hsqldb</artifactId>
<version>2.3.1</version>
OS: Windows 7 x64
The rules around this are explained in the HSQLDB documentation:
When a database object is created with one of the CREATE statements or
renamed with the ALTER statement, if the name is enclosed in double
quotes, the exact name is used as the case-normal form. But if it is
not enclosed in double quotes, the name is converted to uppercase and
this uppercase version is stored in the database as the case-normal
form.
Case sensitivity rules for identifiers can be described simply as
follows:
all parts of SQL statements are converted to upper case before processing, except identifiers in double quotes and strings in single
quotes
identifiers, both unquoted and double quoted, are then treated as case-sensitive
most database engines follow the same rule, except, in some respects, MySQL and MS SQLServer.
AFAIK this behaviour can't be turned off. (It's worth noting that standard SQL is case-insensitive when quoted identifiers aren't used.) But as mentioned above, a lower case identifier can be specified by enclosing in quotes, e.g:
CREATE TABLE "lowercasetablename" ("lowercasecolname" INT);
SELECT "lowercasecolname" FROM "lowercasetablename";
I am not sure, i understand the problem correctly but just trying to put some effort.
SET DATABASE COLLATION SQL_TEXT_UCC
May be you can refer http://hsqldb.org/doc/guide/dbproperties-chapt.html
when I write a sql statement in php, i usualy write it as below
SELECT COUNT(*) FROM catalogsearch_query AS main_table
but I found that some people write sql statement like
SELECT COUNT(*) FROM `catalogsearch_query` AS `main_table`
do I have to use ` ?
You don't have to use backticks. However when you're using reserved keywords as table or field names, then you have to enclose them in backticks for them to work.
From MySql docs:
Database, table, index, column, and alias names are identifiers. An identifier may be quoted or unquoted. If an identifier contains special characters or is a reserved word, you must quote it whenever you refer to it.
We use the backtick ` for quoting.