I want to create a SQL Server database that will hold thousands of tables who's names will reflect stock ticker names. For example, '0099-OL.HK' is a company's ticker name. Many of the stocks I'm creating tables for have special characters in them just like that.
I've read that special characters in table names should be avoided, but I still don't know why. SQL Server lets you use special characters in table names if you enclose the name with brackets, e.g., 'CREATE TABLE [0099-OL.HK] ...'.
Should I use the ticker names as their table names, or should I avoid using their special characters?
This will lead to no end of problems. The reason SQL Server allows names with spaces and special characters is because people migrate from databases that allow these characters in their names. If you must do this replace all special characters with _ like so: TN0099_OL_HK (TN for ticker name) so users can type sql without using the brackets.
It is bad practice to do so, since not every library might be able to process the table name correctly.
Avoid using special characters, spaces, and leading numbers in database names, table names, and column names.
For the full Rules for Regular Identifiers: Database Identifiers - docs
Related
Inside my database I have some tables that use a column with a reserved word name for example user, I have created it using " as "USER" but when I want to get it I have realized that I have to put it in capital letters, I have already investigated and I obtained that when placing " oracle respects it as case sensitive, they somehow know how to avoid this and obtain my column without the need for it to be written as defined, that is, case insensitive.
I am working Oracle with Firedac, on the Firedac side, do you know if something can be done so that this can be solved by having to put the column name as it is?
No.
You chose to have a column that conflicts with a reserved word, so you had to quote it when you declared it. You also need to quote this identifier everytime you use it - and a quoted identifier is case-sensitive by design.
I would strongly suggest avoiding having column names that conflict with SQL reserved word (or keywords). There is no benefit, and many drawbacks. You could just rename that column to usr, username, userid, or else. Declare the new name as a unquoted identifier, and you will never need to worry about this all afterwards.
I put together an Access Database for a department. They've been using it frequently for the past few months with no hiccups.
However, they changed one of the field names of a linked Excel File, which forces me to go into Access and update the query a bit.
The field name has gone from "PacU" to "Mr. Cooper"
Original:
SELECT Round(BidTemplate.[PacU],6) AS PacU
New:
SELECT Round(BidTemplate.[Mr. Cooper],6) AS [Mr. Cooper]
I am receing an error as follows "Invalid bracketing of the name 'BidTeample.[Mr.Cooper]'.
I'm sure the issue is driven off of the period that is now included in the field. But shouldn't the brackets take care of this?
What am I missing?
Field names cannot contain a period.
From the MS Access Documentation:
Names of fields, controls, and objects in Microsoft Access desktop databases:
Can be up to 64 characters long.
Can include any combination of letters, numbers, spaces, and special characters except a period (.), an exclamation point (!), an
accent grave (`), and brackets ([ ]).
Can't begin with leading spaces.
Can't include control characters (ASCII values 0 through 31).
Can't include a double quotation mark (") in table, view, or stored procedure names in a Microsoft Access project.
remove extra space
SELECT Round(BidTemplate.[Mr Cooper],6) AS [Mr Cooper]
I am facing an issue while fetching the data via query from a redshift table. For example:
table name: test_users
column names: user_id, userName, userLastName
Now while creating the test_users table it converts the capital letter of the userName column to username and similar with userLastName which will be converted to userlastname.
I have found the way to convert the all columns to capital or in lowercase, but not in the way to get it as it is.
Unfortunately, AWS Redshift does not support case-sensitive identifiers at the time of writing (Feb 2020). And, while Redshift is based on PostgreSQL, AWS has heavily modified it to the point where many assumptions that would be correct for PostgreSQL 8 are not correct for Redshift.
The documentation at https://docs.aws.amazon.com/redshift/latest/dg/r_names.html explicitly states that it downcases identifiers. The relevant paragraph is below, with the critical sentence bolded:
Names identify database objects, including tables and columns, as well as users and passwords. The terms name and identifier can be used interchangeably. There are two types of identifiers, standard identifiers and quoted or delimited identifiers. Identifiers must consist of only UTF-8 printable characters. ASCII letters in standard and delimited identifiers are case-insensitive and are folded to lowercase in the database. In query results, column names are returned as lowercase by default. To return column names in uppercase, set the describe_field_name_in_uppercase configuration parameter to true.
To preserve case:
SET enable_case_sensitive_identifier TO true;
https://docs.aws.amazon.com/redshift/latest/dg/r_enable_case_sensitive_identifier.html
To force returned uppercase fields (for anyone else curious):
SET describe_field_name_in_uppercase TO on;
https://docs.aws.amazon.com/redshift/latest/dg/r_describe_field_name_in_uppercase.html
Square brackets allow you to use names for columns or aliases that contain characters not permitted for column names or aliases.
a) I’ve noticed that lots of times table and column names are enclosed inside square brackets, even though their names consist of perfectly legal characters. Why is that?
b) As far as I know, square brackets enclosing object’s name aren’t actually a part of that name. Thus, if we create a table named [A]:
CREATE TABLE [A] ( … )
we can later reference it without using brackets:
SELECT * FROM A
But why isn’t the same true when I try to reference a column KEY from a table returned by CONTAINSTABLE function? Namely, if I omit the brackets enclosing column name, I get an error:
SELECT ct.KEY
FROM CONTAINSTABLE(fullText,*,'some_string') as ct
thanx
KEY is a reserved word in SQL so requires the brackets to use it as a column name.
I think lots of the time you see superfluous square brackets may well be code generated by a tool. Management Studio puts them on when generating some scripts.
Brackets are not just for legal characters but to allow the use of otherwise reserved words for column names, etc.
What is the difference between single quotes and double quotes in SQL?
Single quotes are used to indicate the beginning and end of a string in SQL. Double quotes generally aren't used in SQL, but that can vary from database to database.
Stick to using single quotes.
That's the primary use anyway. You can use single quotes for a column alias — where you want the column name you reference in your application code to be something other than what the column is actually called in the database. For example: PRODUCT.id would be more readable as product_id, so you use either of the following:
SELECT PRODUCT.id AS product_id
SELECT PRODUCT.id 'product_id'
Either works in Oracle, SQL Server, MySQL… but I know some have said that the TOAD IDE seems to give some grief when using the single quotes approach.
You do have to use single quotes when the column alias includes a space character, e.g., product id, but it's not recommended practice for a column alias to be more than one word.
A simple rule for us to remember what to use in which case:
[S]ingle quotes are for [S]trings Literals (date literals are also strings);
[D]ouble quotes are for [D]atabase Identifiers;
Examples:
INSERT INTO "USERS" ("LOGIN", "PASSWORD", "DT_BIRTH") VALUES ('EDUARDO', '12345678', '1980-09-06');
In MySQL and MariaDB, the ` (backtick) symbol is the same as the " symbol. And note that you can't use " for literal strings when your SQL_MODE has ANSI_QUOTES enabled.
Single quotes delimit a string constant or a date/time constant.
Double quotes delimit identifiers for e.g. table names or column names. This is generally only necessary when your identifier doesn't fit the rules for simple identifiers.
See also:
Do different databases use different name quote?
You can make MySQL use double-quotes per the ANSI standard:
SET GLOBAL SQL_MODE=ANSI_QUOTES
You can make Microsoft SQL Server use double-quotes per the ANSI standard:
SET QUOTED_IDENTIFIER ON
In ANSI SQL, double quotes quote object names (e.g. tables) which allows them to contain characters not otherwise permitted, or be the same as reserved words (Avoid this, really).
Single quotes are for strings.
However, MySQL is oblivious to the standard (unless its SQL_MODE is changed) and allows them to be used interchangably for strings.
Moreover, Sybase and Microsoft also use square brackets for identifier quoting.
So it's a bit vendor specific.
Other databases such as Postgres and IBM actually adhere to the ansi standard :)
I use this mnemonic:
Single quotes are for strings (one thing)
Double quotes are for tables names and column names (two things)
This is not 100% correct according to the specs, but this mnemonic helps me (human being).
Two Things To Remember :
Single Qutoes(') : String Or Text
select * from employees where room_name = 'RobinCapRed';
where RobinCapRed is a string or a text.
Double Quotes(") : Column Names or Table Names
select "first_name" from "employees";
where first_Name is a column name from employees table
The difference lies in their usage. The single quotes are mostly used to refer a string in WHERE, HAVING and also in some built-in SQL functions like CONCAT, STRPOS, POSITION etc.
When you want to use an alias that has space in between then you can use double quotes to refer to that alias.
For example
(select account_id,count(*) "count of" from orders group by 1)sub
Here is a subquery from an orders table having account_id as Foreign key that I am aggregating to know how many orders each account placed. Here I have given one column any random name as "count of" for sake of purpose.
Now let's write an outer query to display the rows where "count of" is greater than 20.
select "count of" from
(select account_id,count(*) "count of" from orders group by 1)sub where "count of" >20;
You can apply the same case to Common Table expressions also.