By default - Are all oracle table names and columns stored in uppercase?
Could I change to casing?
In the data dictionary, yes, identifiers are converted to upper case by default.
You can change that behavior by creating case-sensitive identifiers. It is generally not a good idea to do so, but you can. In order to do so, you would need to enclose the table name and column names in double quotes both when you create the object and every time you want to refer to them. You'll also need to get the casing right because the identifiers will be case-sensitive unlike the normal case-insensitive behavior.
If you
CREATE TABLE "foo" (
"MyMixedCaseColumn" number
);
then the table name and column name will be stored in mixed case in the data dictionary. You'll need to use double-quotes to refer to either identifier in the future. So
SELECT "MyMixedCaseColumn"
FROM "foo"
will work. However, something like
SELECT MyMixedCaseColumn
FROM foo
will not. Nor will
SELECT "MyMixedCaseColumn"
FROM "Foo"
Generally, future developers will be grateful if you don't use case-sensitive identifiers. It's annoying to have to use double-quotes all over the place and not every tool or library has been tested against systems that use case-sensitive identifiers so it's not uncommon for things to break.
Related
I multiple tables in my database. All of my tables are showing output using select query instead of only 1 table "case". it also have data and columns but when I use it in my query it shows syntax error. I have also attached picture which have list of table and a simple query. This code is not developed by me so I am not sure why it is showing error. Is there any kind of restriction we can set so that it cannot be used in queries?
CASE is a reserved keyword in SQL Server. Therefore, you must escape it in double brackets:
SELECT * FROM dbo.[Case];
But best naming practice dictates that we should avoid naming database objects using reserved keywords. So, don't name your tables CASE.
Reserved words are not recommended for use as a database, table, column, variable, or other object names. If you desire to use a reserved word is used as an object name in ANSI standard syntax, it must be enclosed in double-quotes OR "[]" to allow the Relational Engine (whichever that one is) that the word is being used as an object and not as a keyword in the given context. Here is the sample code.
SELECT * FROM dbo."Case"
Or
SELECT * FROM dbo.[Case]
I have oracle express installation, and by default it is case insensitive ( table creation/ keys name ). I want to change it to case sensitive. Is there a configuration to do so?
There is no setting, no.
In any version of Oracle, however, you can use case-sensitive identifiers by enclosing them in double-quotes.
create table "CamelCase" (
"ColumnName1" integer
);
will create a table CamelCase which is case-sensitive and a column ColumnName1 that is case sensitive. In order to use the column, though, every reference will need to be surrounded in double-quotes
SELECT "ColumnName1"
FROM "CamelCase"
would work. However
SELECT ColumnName1
FROM CamelCase
would not.
Using case-sensitive identifiers is generally a really bad idea so I would strongly suggest that you don't do so. It is an option though.
No, there is no configuration for that. You can't make identifiers case-sensitive without quoting them, but Oracle recommends against using quoted identifiers:.
Oracle does not recommend using quoted identifiers for database object names. These quoted identifiers are accepted by SQL*Plus, but they may not be valid when using other tools that manage database objects.
And even then if you have a quoted identifier that is all-caps anyway, e.g. "MY_TABLE", that is treated the same as an unquoted identifier so you can still refer to it as my_table, which might not be case-sensitive enough for you. Anything mixed-case or with invalid characters always has to be referred to quoted though, e.g. `select * from "My Table", which makes code harder to read and maintain (in my opinion anyway).
I'd really recommend not doing this. Anyone having to maintain your schema or code will not thank you for it.
Question:
How can I (programmatically) obtain a complete list of reserved keywords in Sybase?
Specifically, ones that can not be a column name in a table.
Alternately, how can I check whether a specific identifier is a reserved keyword in Sybase?
Background:
I have a process which takes a comma separated file with headers and loads into a temp table in Sybase.
The goal is to have the temp table column names match the file column names.
This will fail if the file has a column named after a reserved keyword.
I'd like to catch that scenario BEFORE the CREATE TABLE statement fails.
Notes:
I am looking for a Sybase-version-independent solution.
Therefore "copy all the words in Sybase Reference Manual (e.g. this for v.12.5) is NOT a valid answer. I'm perfectly aware I can do that. But it will not work in Sybase 15 without changing the keyword list by hand.
If the solution exists but not available in earlier Sybase versions, I need something compatible with Sybase 12.5 and later
I'm also perfectly aware of how to do this by creating a table with any words I have, trapping CREATE TABLE failure, and reading which word failed. I'm looking for a more elegant solution if available.
Found a way after more Googling!
select name from master..spt_values where type="W"
First, turn on "quoted_identifier" in your config (set quoted_identifier on). Then escape all your column names with double quotes.
That way you don't need to catch which ones are reserved words, and all columns will have the names you expect them to have.
I am maintaining a database created by another person in SQL Server. In one table I found a column whose name is between square brackets. The name of the field is desc and it is stored in the table as [desc]. The other fields are stored without square brackets. Is there any special reason/convention behind this choice?
The applications built on top of the Database are developed either in C# or VB.NET.
Thanks
The brackets (or other identifiers in other database engines) are just an explicit way of telling the query engine that this term is an identifier for an object in the database. Common reasons include:
Object names which contain spaces would otherwise fail to parse as part of the query unless they're wrapped in brackets.
Object names which are reserved words can fail to parse (or, worse, correctly parse and do unexpected things).
(I suppose it's also possible that there may be an ever-so-slight performance improvement since the engine doesn't need to try to identify what that item means, it's been explicitly told that it's an object. It still needs to validate that, of course, but it may be a small help in the inner workings.)
If your names contains either a reserved word (such as SELECT) or spaces, then you need to surround the name with [].
In your example, you have [desc], which is short for DESCENDING.
For example if you have a field that is a keyword e.g [Date] or [Select] or in this case [desc]
In SQL Server, why is this:
[dbo].[table_name]
preferable to this:
dbo.table_name
And along those lines, why even list the dbo at all if there's only one schema?
If the table name contains key words, you will have to enclose it inside [ ]. Most of the tools (like ORM) use this technique to avoid any errors or for consistency.
It's just in case you have a keyword as a tablename like [user]
It allows keywords or punctuation in a table name.
It's often used by code generators for all names, so they don't have to figure out if it actually needed.
These usually come up in generated code - because it's easier to make the code generation produce fully-qualified and escaped references than to deduce what escaping/qualification is required when.
If there is only one schema then prefixing the table name is not necessary or useful I think. Using the brackets [] is useful when you have an identifier that is a reserved word in sql server. If, for instance, you have a table named Select you can refernce it as SELECT * FROM [Select] but not as SELECT * FROM Select.
I don't use the brackets, which are only necessary if you use keywords as schemas or table names, which you shouldn't.
But I would recommend against dropping the dbo at the front. The reason is that eventually you might want to start organizing your code into schemas, and then you will need the prefix. If you get in the habit of using the schema.table format, it will be a lot easier to search your code for places where the tables are used.
Let's say you have a table called dbo.user, and you decide to move it to another schema. If you have to search through a bunch of stored procedures or dynamic sql for "user", you will likely get a ton of false positives. You can't be totally sure that you made all the changes you needed to. Searching for "dbo.user" is a lot more concise.
The [] are only required if the object name contains characters like spaces or if it is a keyword. It is generally regarded as best practice not to use any of these as object names so you should never need the []. Having said that they also do no harm, if it is generated code and includes the brackets then you may as well leave them.
Using dbo is a good idea becuase
Performance is better (see here for some figures)
dbo is required in some cases, like calling user defined functions. I think it is tidyer to always include it.
Not qualifying the object name could lead to bugs in the future if you do create multiple schemas.
Doesn't this allow you to have whatever 'bad' items you desire in there?
Keywords, spaces, etc...
I would prefer to avoid using punctuation and reserved words in table and column names, and not use the square brackets. This makes the SQL far easier to read.
Apart from spaces, reserved keywords, and system functions in an identifier name, an identifier can also contain some characters that are not allowed in regular identifiers, an it has to be separated with square brackets.
You can find a detailed explanation and rules for regular and delimited identifiers in this article.
From the article:
For example, delimited identifiers can contain spaces, any characters
valid for regular identifiers, and any one of the following
characters:
tilde (~) hyphen, (-) exclamation point (!), left brace ({), percent (%),
right brace (}), caret (^), apostrophe ('), ampersand (&), period (.), left
parenthesis ((), backslash (), right parenthesis ()), accent grave (`),
Using two name qualifying convention may improve performance (avoid name resolutions) and avoid ambiguity in cases when you have e.g. the same table name in two or more schema. In that case SQL Server will search your object in dbo and if it isn't there it will stop searching.
Also if you later want to use that object with the SCHEMABINDING option it doesn't allow unqualified object names.
Hope this helps