I'm adding a table to my database - CREATE TABLE dbo.Card - and SSMS is highlighting the word Card. I'm searching the internet trying to find out what that word means to SQL and if it is a keyword or not. I don't see it anywhere on Microsoft's list of SQL Reserved Words.
The main reason I care, aside from the highlighting bothering me, is that I want to avoid using any reserved words or keywords as schema/table/column/etc... names. When I absolutely have to - existing databases - I like to use square brackets to make things explicit.
Is Card a reserved word or keyword in SQL, or for any other reason unsafe to use as an identifier?
If it is safe to use, can anyone explain why SSMS is highlighting it?
If it is not 100% safe to use as a table name I'll most likely choose a different name.
Windows 8.1
SSMS v17.7
Red Gate - Up to date, including SQL Prompt 9.4.9
SQL Server 2017 (14.0)
Database Compatibility Level 2017 (140)
UPDATE
It looks like the main consensus is:
It is not a reserved or keyword
SSMS highlights it because reasons... It's probably used somewhere by MS SQL Server or SSMS
At this point I'm just terribly curious, but at least I know there's no need to worry. Thanks everyone for your answers.
No, card is not a reversed word in Microsoft SQLServer or SQL ANSI standard.
Card is definitely not a reserved keyword in SQL Server
You can check the complete list of reserved words Reserved Keywords (Transact-SQL)
SSMS highlights it because reasons... It's probably used somewhere by
MS SQL Server or SSMS
They are various keywords that have been subjectively chosen by Microsoft and placed into a list within the query editor syntax coloring file.
I suggest it's always good to use Delimited Identifiers ([] or ") when specifying table name and column names.
For example, the script you are using should be written as
CREATE TABLE [dbo].[Card](<Columns>)
Related
Can anybody tell me what does the error mean? Whenever I open the query builder it will prompt with an error indicating that SQL syntax errors were encountered.
https://msdn.microsoft.com/en-us/library/ms189012.aspx
I looked at the following page in MSDN but I don't understand what it means...
For instance, what do these bullet points from the MSDN article mean?
The SQL statement is incomplete or contains one or more syntax errors.
The SQL statement is valid but is not supported in the graphical panes (for example, a Union query).
The SQL statement is valid but contains syntax specific to the data connection you are using.
USER (which you've apparently decided is an appropriate table name) is a SQL Server reserved word.
The best solution is to rename your table, so you don't have to escape the table name every time you want to query it and to make it clear it's your user data (hey, there's a table name suggestion - userdata).
The other option is to escape the name by surrounding it with square brackets:
SELECT * FROM [users]
Note that it will get old fast having to do this with every query. Again, the best solution would be to rename the table to something that isn't a reserved word.
I have a requirement to do something I believe should be simple enough, but am not finding the right answer to. How do I use a checkmark as a column alias in SQL Server 2008 R2?
I've tried using Char(251) by setting it to a value and trying to assign the value as the column alias, but no joy on that one.
I've tried using Char(251) (and I know that's more of a square root mark, but not sure of the checkmark ascii value if there is one. I believe that is a unicode value?) directly but again no joy. This should be simple, but I'm simply not finding it.
Thanks.
You cannot use expressions as identifiers in SQL Server (or any other SQL database for that matter). You can, however, use Unicode characters in identifiers, so simply copy and paste the desired character:
select 'yes' as "☑︎";
or even
select 'blah' as "😀";
Having said that, you should not be doing all that -- presentation is not the task for a database engine; it should be implemented in the client application.
I was writing a Stored Procedure today and Wrote the line:
SELECT pv1.Version FROM depl...
and the word Version turned blue shown below:
so I assumed it was a reserved word, so did some investigating here:
Reserved Keywords (TRANSACT-SQL)
But could not find the word Version in the list.
Is Version a SQL reserved word, and if not why is my word Version displaying blue? I am using SQL Management Studio 2012
As you rightly noted, Version is not in the official reserved word list. It's just a "feature" of SQL Server Management Studio that is showing it in blue.
There are many words like this. Here's a few more:
DESCRIPTION
SERVER
INSTEAD
There are even some words that show as pink such as LOOKUP.
"Version" is not a SQL Server reserved keyword.
However, it is used in a global variable used to show the OS name & version, SQL Server version, SQL Server patches and hardware attributes of the SQL Server being used.
SELECT ##VERSION
Perhaps the "Version" text turns blue in Transact-SQL because it is known to SQL Server in the context of this global variable. I'm not sure about that, this is just a theory.
The short answer - no, it isn't. Here's an SQLFiddle that uses it as a column name in SQL-Server 2014 to prove it.
I think you can always if in doubt wrap your column name in brackets to use reserved words as column names:
select p1.[Version] from dpl...
I have SQL Server 2008 Express Edition installed and is my first time running a SQL query. I noticed that if I select to display the top 1000 rows that the query places brackets [] around the name of the database and its respective columns.
Why are there brackets around the name of the database and columns?
Is there a need to have these and if so when?
I just posted this answer on dba.stack.
They escape names that are not "friendly" - they can be useful if your database names contain special characters (such as spaces, dots or dashes) or represent SQL keywords (such as USE or DATABASE :-)). Without the square brackets, a query like this will fail:
SELECT column FROM database.dbo.table;
However if you write the query this way, the keywords are ignored:
SELECT [column] FROM [database].dbo.[table];
When building scripts or writing solutions that generate scripts from metadata (e.g. generating a script of all tables or all indexes), I always wrap entity names in square brackets so that they will work regardless of what kind of wonky names have been implemented (I am not always doing this for systems I control). You can do this easily using QUOTENAME function, e.g.:
SELECT QUOTENAME('table'), QUOTENAME('column'), QUOTENAME('database');
Results:
[table] [column] [database]
If you search my answers here for QUOTENAME you will find that I use it in a lot of scripts where I'm helping folks automate script generation or building dynamic SQL. Without the square brackets, a lot of people would run into issues running the scripts.
Enclosing a string in square braces is tells SQL Server that it should not try to parse whatever is inside them. This allows you to do use things like SQL reserved words (select, table, return, etc.) as well as spaces in identifiers. They are only required in those cases, but they are not harmful in any case.
No there isn't, but it ensures that if you had a db, table or column named as a reserved or keyword, for example date, that it wouldn't be confused with that keyword.
Full error message: "[Microsoft][ODBC Excel Driver] The LEVEL clause includes a reserved word or argument that is mispelled or missing, or the punctuation is incorrect"
I get this when trying to execute a query in one excel document against a table in another excel document. My SQL doesn't include LEVEL at all, and I can't find anything useful on Google.
Before anyone asks: Yes, I know excel isn't a database. I can't find a better way to get this data from sheet to sheet.
Because I like my job, I've obfuscated my SQL; otherwise it includes company confidential data. I am certain that my syntax is right on the things that I am removing, because it was written my Microsoft Query.
SELECT `Table1$`.`Field1`, <Other Fields from Table1>,
`Table2$`.`FieldA`, <Other Fields from Table2>,
`Table3$`.`FieldX`,
`Table3$`.`FieldY`
FROM `<network path starting with \\>\<filename>.xlsb`.`Table1$` `Table1$`,
`<network path starting with \\>\<filename>.xlsb`.`Table2$` `Table2$`,
`<network path starting with \\>\<filename>.xlsb`.`Table3$` `Table3$`
WHERE `Table2$`.`Join1Field` = `Table1$`.`Join1Field`
AND `Table3$`.`Join2Field` = `Table1$`.`Join2Field`
AND `Table1$`.`Weeks Ago` < 14;
Note: All of these tables are in the same Excel file, and I'm using Excel 2007.
According to this page on MSDN you entered an SQL statement that has an invalid reserved word or incorrect punctuation. As #Ken White points out, it's hard to tell from your edited SQL what is going on.
IIRC when you use the GUI tool in MS Query it writes ODBC syntax: perhaps there is a problem in translation to native Access (ACE, Jet, whatever) syntax at the Excel end. If you can write SQL without GUI tools, or can use the Access QBE thing to do it for you, IIRC you can paste native Access SQL syntax into MS Query's SQL window and it will 'pass through' to Excel unchanged.