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
Related
I have a customer that their Snowflake instance require the columns name to have double quotes. Example: SELECT "CategoryName" from "lk_category" ;
Does anyone know how to turn this feature off?
The Snowflake documentation does explain a bit about identifiers.
The key point is that quoted identifiers must be referred to exactly as they are defined. So, the following are different:
"ABC"
"abc"
"Abc"
Unquoted identifiers are case-insensitive, so the following are the same:
ABC
abc
Abc
As a bonus, these are also equivalent to:
"ABC"
because Snowflake resolves unquoted identifiers using the upper case.
If the database has already been created with quoted identifiers . . . well, you can go about changing it.
Snowflake has identified this as a problem. You can turn off the quoted behavior by setting the QUOTED_IDENTIFIERS_IGNORE_CASE parameter.
For your question:
SELECT """CategoryName""" FROM lk_category
…is the answer. I had a similar issue with double pivot tables.
Please check it using:
Describe View/Table Table/View_Name
We will get the list of Column Names, If a field name with double quote Ex:"Name" is present.
Then to select it we should use extra quotes as escape characters.
I'm currently using Oracle SQL developer and am trying to write a query that will allow me to search for all fields that resemble a certain value but always differ from it.
SELECT last_name FROM employees WHERE last_name LIKE 'Do[^e]%';
So the result that I'm after would be: Give me all last names that start with 'Do' but are not 'Doe'.
I got the square brackets method from a general SQL basics book so I assume any SQL database should be able to run it.
This is my first post and I'd be happy to clarify if my question wasn't clear enough.
In Oracle's LIKE no regular expressions can be used. But you can use REGEXP_LIKE.
SELECT * FROM EMPLOYEES WHERE REGEXP_LIKE (Name, '^Do[^e]');
The ^ at the beginning of the pattern anchors it to the beginning of the compared string. In other words the string must start with the pattern to match. And there is no wildcard needed at the end, as there is no anchor for the end of the string (which would be $). And you seem to already know the meaning of [^e].
This is very simple but somehow I'm doing something wrong with this query on my database.
I have this query below:
SELECT login FROM accounts WHERE login = "loginname";
When I execute this query the result I get is this:
column "loginname" does not exist
This is a no brainer, why is this query not working properly? I have a login column and I know that this user exists because I've found this person with the rails console. Why is the login criteria referring to itself as a column?
Try with single quotes '' if you are trying to match a string
SELECT login FROM accounts WHERE login = 'loginname';
Check the documentation
There is a second kind of identifier: the delimited identifier or
quoted identifier. It is formed by enclosing an arbitrary sequence of
characters in double-quotes ("). A delimited identifier is always an
identifier, never a key word. So "select" could be used to refer to a
column or table named "select", whereas an unquoted select would be
taken as a key word and would therefore provoke a parse error when
used where a table or column name is expected.
Double quotes (") are used to refer to object names, in a case sensitive way. In this case, "loginname" is interpreted as a column name, and the query fails, since there is no such column. In order to refer to a string literal, you should use single quotes ('):
SELECT login FROM accounts WHERE login = 'loginname';
-- Here ---------------------------------^---------^
It seems that the " " are the problem if you believe the documentation. Single quotes are required for string values.
From the PostgreSQL Documentation:
There is a second kind of identifier: the delimited identifier or quoted identifier. It is formed by enclosing an arbitrary sequence of characters in double-quotes ("). A delimited identifier is always an identifier, never a key word. So "select" could be used to refer to a column or table named "select", whereas an unquoted select would be taken as a key word and would therefore provoke a parse error when used where a table or column name is expected. The example can be written with quoted identifiers like this:
UPDATE "my_table" SET "a" = 5;
Quoted identifiers can contain any character, except the character with code zero. (To include a double quote, write two double quotes.) This allows constructing table or column names that would otherwise not be possible, such as ones containing spaces or ampersands. The length limitation still applies.
So in your query "loginname" is the same as having loginname without quotes - it's attempting to refer to a column with that name. To make it a literal string, use single-quotes instead.
I am running below query in Teradata :
sel requesttext from dbc.tables
where tablename='old_employee_table'
Result:
alter table DB_NAME.employee_table,no fallback ;
I want to get below result using SQL:
DB_NAME.employee_table
Requesttext can be:
create set table DB_NAME.employee_table;
DB Name and table can occur anywhere in the result. Since .(dot) is joining them that's why i want to split with .(dot).
Basically I need sql which can result me surrounding values of .(dot)
I want DBName and Tablename in result.
I'm not a Teradata person, but this should work for both strings given so far, as long as teradata's regexp_substr() supports positive look-behind and positive look-ahead assertions (I might have the Teradata syntax wrong, so a little tweaking may be needed):
SELECT REGEXP_SUBSTR(requesttext, '(?<= )(\w+\.\w+)(?=[,$]?)', 1, 1)
FROM dbc.tables
WHERE tablename='old_employee_table'
See the regex101 example. Hopefully it translates to Teradata easily.
The regex looks for and returns the words either side of and including the period, when preceded by a space, and followed by an optional comma or the end of the line.
You could do this with either regexp_substr() or strtok().
As Jamie Zawinski said:
Some people, when confronted with a problem, think "I know, I'll use
regular expressions." Now they have two problems.
So I would go with the strtok() method. Also I'm lazy and regular expressions are hard.
Function strtok() takes three arguments:
The string being split
The delimiter to split the string
The number of the token to grab.
To get at the <database>.<table> from that string that is returned in your query, we can split by a space, grab the third token, then split that by a comma and grab the first token.
That would look like:
SELECT strtok(strtok(requestText,' ',3),',',1)
FROM dbc.tables
WHERE tablename='old_employee_table'
I tried to create table named 15909434_user with syntax like below:
CREATE TABLE 15909434_user ( ... )
It would produced error of course. Then, after I tried to have a bit research with google, I found a good article here that describe:
When you create an object in PostgreSQL, you give that object a name. Every table has a name, every column has a name, and so on. PostgreSQL uses a single data type to define all object names: the name type.
A value of type name is a string of 63 or fewer characters. A name must start with a letter or an underscore; the rest of the string can contain letters, digits, and underscores.
...
If you find that you need to create an object that does not meet these rules, you can enclose the name in double quotes. Wrapping a name in quotes creates a quoted identifier. For example, you could create a table whose name is "3.14159"—the double quotes are required, but are not actually a part of the name (that is, they are not stored and do not count against the 63-character limit). ...
Okay, now I know how to solve this by use this syntax (putting double quote on table name):
CREATE TABLE "15909434_user" ( ... )
You can create table or column name such as "15909434_user" and also user_15909434, but cannot create table or column name begin with numeric without use of double quotes.
So then, I am curious about the reason behind that (except it is a convention). Why this convention applied? Is it to avoid something like syntax limitation or other reason?
Thanks in advance for your attention!
It comes from the original sql standards, which through several layers of indirection eventually get to an identifier start block, which is one of several things, but primarily it is "a simple latin letter". There are other things too that can be used, but if you want to see all the details, go to http://en.wikipedia.org/wiki/SQL-92 and follow the links to the actual standard ( page 85 )
Having non numeric identifier introducers makes writing a parser to decode sql for execution easier and quicker, but a quoted form is fine too.
Edit: Why is it easier for the parser?
The problem for a parser is more in the SELECT-list clause than the FROM clause. The select-list is the list of expressions that are selected from the tables, and this is very flexible, allowing simple column names and numeric expressions. Consider the following:
SELECT 2e2 + 3.4 FROM ...
If table names, and column names could start with numerics, is 2e2 a column name or a valid number (e format is typically permitted in numeric literals) and is 3.4 the table "3" and column "4" or is it the numeric value 3.4 ?
Having the rule that identifiers start with simple latin letters (and some other specific things) means that a parser that sees 2e2 can quickly discern this will be a numeric expression, same deal with 3.4
While it would be possible to devise a scheme to allow numeric leading characters, this might lead to even more obscure rules (opinion), so this rule is a nice solution. If you allowed digits first, then it would always need quoting, which is arguably not as 'clean'.
Disclaimer, I've simplified the above slightly, ignoring corelation names to keep it short. I'm not totally familiar with postgres, but have double checked the above answer against Oracle RDB documentation and sql spec
I'd imagine it's to do with the grammar.
SELECT 24*DAY_NUMBER as X from MY_TABLE
is fine, but ambiguous if 24 was allowed as a column name.
Adding quotes means you're explicitly referring to an identifier not a constant. So in order to use it, you'd always have to escape it anyway.