Creating table names, reserved words / keywords in MS SQL Server

Can I name my database tables that are already keywords? In my case, I am trying to name the table in which my users will be stored. I named it User , but it appears pink in SQL Server Management Studio, so I assume its existing System table or keyword. Thank you for your advice.

Official Reserved Keyword List: Reserved Keywords (Transact-SQL)

+44
sql sql-server
Mar 29 '09 at 23:06
source share
12 answers

repeat this three times:

DO NOT DO IT, I DO NOT USE FORBIDDEN WORDS!

you thank me!

+83
Mar 29 '09 at 23:34
source share

You can create tables with the same name as keywords. If you "specify" a table name, it should work. SQL Server default quotes are enclosed in square brackets: []

CREATE TABLE [dbo].[user]( [id] [bigint] NOT NULL, [name] [varchar](20) NOT NULL ) ON [PRIMARY] 
+56
Mar 29 '09 at 23:12
source share

Yes, everything is in order. In your queries, you can put [and] around the name of your table so that SQL Server knows that you are referencing the table - i.e.

 CREATE TABLE [User] ... SELECT * FROM [User] 
+7
Mar 29 '09 at 23:13
source share

You can use [User] for this. If possible, use a table name that does not conflict with the keyword to avoid confusion and errors.

+6
Mar 29 '09 at 23:12
source share

For columns , use the single quotation mark for rows and the double quotation mark for column names.

Example:

 INSERT INTO AccountMovement ("Date", Info) VALUES ('2012/03/17', 'aa'), ('2012/03/17', 'bb'), ('2012/03/17', 'cc'), ('2012/03/17', 'dd') 
+5
Apr 25 2018-12-12T00:
source share

I am sitting in a camp, which says that the table names must be multiple, so in your case these will be users.

I like this agreement because it makes sense to me. You have a collection of users, so call your spreadsheet. Further downstream, if you pull out a separate line, which can then populate an object named "User".

If your convention dictates the use of the singular for table names, use something else, for example: Member, Client, etc.

Also see RacerX answer!

As mentioned earlier, this is technically normal if you named [Brand].

+4
Mar 30 '09 at 0:51
source share

In MS Query, I found that double quotes work fine in a query.

 select T1."Reference" from MyTable T1 
+3
Dec 01 '10 at 20:18
source share

As already mentioned, you can do this by specifying a name. Of course, you will also have to quote this name at any time when you refer to it - believe me, it will quickly become old.

As an aside, simply because the syntax colors are SSMS, this word does not necessarily mean a reserved word . Sql can be so annoying.;)

+1
Mar 29 '09 at 23:52
source share

The basic rule for table and column names (or, better, object names):

Do not use anything the same as a reserved word or even the like. Use only A-Za-z0-9 and underline. Especially do not use spaces. Use only names that do not require escaping, and then do not use escaping as an eternal test.

You, and everyone who works with you or will ever work on your code, does not need to be aggravated.

+1
Mar 30 '09 at 0:16
source share

As everyone else said, do not do this; however, I was in the same boat. I have a rule that says that all my tables are stored in a single form. Organization, not organization, Asset not Assets a PartsCatalog has many parts, etc.

Well, I have a User table, so what do I call it? I ended up running away from him [User]. Now I regret this decision because I always forget to avoid the table; however, I have not yet come up with a better name: the member is the leading candidate.

0
Apr 03 '09 at 13:26
source share

Not a good idea - for various reasons.

MORE REASONS, WHY NOT 1) The obvious possible conflict with the reserved names 2) If after two years you want to make a global replacement in your code for the word "user" in the form field or in any place where you were screwed when using common names 3) If you need to look for cases that use the "user" in your code, you know where this happens (we have more than a million lines of code, this will kill us).

WHAT WE ARE 1) each table name has a unique start, such as O_nnn for F_nnn objects for financial data ... we applied the same to fields like opp_created for the opportunity created by date, SUSR_RID to refer to the user ID within the function sales compared to the OPUSR_RID operational link to the user ... 2) In addition to the prefix, we use as obvious names as possible, such as O_FlightArrivalTime, and not O_FltAT. Databases today do not show performance degradation with longer names. 3) Now, when you use OF_FlightArrivalTime as the form name, you can easily find the association, but the global search O_F ... will only search the DB field, search OF_F ... form fields and _F .... both,

0
Nov 15 '14 at 16:03
source share

I would definitely advise against using the reserved keyword as you do. The way our database was designed is to prefix the names of database objects to prevent such an event. For example, here is a brief definition of how I create the User table:

 CREATE TABLE tblUser ( intUserId INT ,vchUsername VARCHAR(255) ,vchEmailAddress VARCHAR(255) ,bitIsAccountEnabled BIT ,dteUpdated DATETIME ,dteCreated DATETIME ,intUpdateUserId INT ) 

That way when I write queries. I have no problem understanding what types of data I am facing. I also don't have to worry about reserved keywords in table names.

0
Nov 15 '14 at 16:18
source share



All Articles