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>)
So, I know my code for the database connection and reader is functional, because it has worked for me many times before, however, something about this SQL query:
gives this error message:
when this data is inputted:
This is the database table that I am trying to add the data to:
The issue is that you are using "password" as a column name and that's a reserved word in Jet SQL. Either change the name or escape it in SQL code. You do the latter by wrapping it in square brackets [].
I'm trying to run a report in Access that references a poorly named column: Vendor#. For those of you not familiar with Access: '#' is a reserved keyword with special meaning. I've been trying to run the report and every time I do a popup appears asking for a value for the column: in other words it keeps seeing it as a variable name. I've tried a number of variations on the name including: [Vendor#], 'Vendor#', ['Vendor#']. I tried an Alias but then I encountered the same issue in the where clause referencing the Alias. No I can't change the schema to rename the column to something more appropriate. Any help is appreciated.
Here is the query:
SELECT * FROM dbo_Vendors
WHERE ((dbo_Vendors.[Vendor#]) = [Forms]![frm_Report_Vendor]![VendorNumber])
I have just tested with a linked sql server table having a column called Vendor#. I can create a report and it runs correctly.
Can you save the query and test that the query runs? I suspect that you may have a misspelled form reference, because I have tested the whole scenario and it works for me. I do not think the report has anything to do with it.
I'm writing a script to create a bunch of tables, and I read in the Microsoft documentation that I should use tick marks (aka grave) to enclose database, table, and field names, but when I run it in SQL Server Management Studio, I get a syntax error on the first tick:
CREATE TABLE `active`.`test` ( … )
^syntax error
So I tried running it thru a lint, and it told me that ` is an invalid character, and it suggested removing them, which totally messed up the script.
What gives?
Use square brackets...
CREATE TABLE [active].[test](...)
The documentation you have linked to is:
The SQL query strings for Windows Installer are restricted to the following formats.
This is not the syntax for SQL Server. I suggest looking at the Transact-SQL Reference instead.
You need to use [] instead of the backtick:
CREATE TABLE [active].[test]
I've hit a bit of an impasse. I have a query that is generated by some C# code. The query works fine in Microsoft SQL Server Management Studio when run against the same database.
However when my code tries to run the same query I get the same error about an invalid column and an exception is thrown. All queries that reference this column are failing.
The column in question was recently added to the database. It is a date column called Incident_Begin_Time_ts .
An example that fails is:
select * from PerfDiag
where Incident_Begin_Time_ts > '2010-01-01 00:00:00';
Other queries like Select MAX(Incident_Being_Time_ts); also fail when run in code because it thinks the column is missing.
Any ideas?
Just press Ctrl + Shift + R and see...
In SQL Server Management Studio, Ctrl+Shift+R refreshes the local cache.
I suspect that you have two tables with the same name. One is owned by the schema 'dbo' (dbo.PerfDiag), and the other is owned by the default schema of the account used to connect to SQL Server (something like userid.PerfDiag).
When you have an unqualified reference to a schema object (such as a table) — one not qualified by schema name — the object reference must be resolved. Name resolution occurs by searching in the following sequence for an object of the appropriate type (table) with the specified name. The name resolves to the first match:
Under the default schema of the user.
Under the schema 'dbo'.
The unqualified reference is bound to the first match in the above sequence.
As a general recommended practice, one should always qualify references to schema objects, for performance reasons:
An unqualified reference may invalidate a cached execution plan for the stored procedure or query, since the schema to which the reference was bound may change depending on the credentials executing the stored procedure or query. This results in recompilation of the query/stored procedure, a performance hit. Recompilations cause compile locks to be taken out, blocking others from accessing the needed resource(s).
Name resolution slows down query execution as two probes must be made to resolve to the likely version of the object (that owned by 'dbo'). This is the usual case. The only time a single probe will resolve the name is if the current user owns an object of the specified name and type.
[Edited to further note]
The other possibilities are (in no particular order):
You aren't connected to the database you think you are.
You aren't connected to the SQL Server instance you think you are.
Double check your connect strings and ensure that they explicitly specify the SQL Server instance name and the database name.
In my case I restart Microsoft SQL Sever Management Studio and this works well for me.
If you are running this inside a transaction and a SQL statement before this drops/alters the table you can also get this message.
I eventually shut-down and restarted Microsoft SQL Server Management Studio; and that fixed it for me. But at other times, just starting a new query window was enough.
If you are using variables with the same name as your column, it could be that you forgot the '#' variable marker. In an INSERT statement it will be detected as a column.
Just had the exact same problem. I renamed some aliased columns in a temporary table which is further used by another part of the same code. For some reason, this was not captured by SQL Server Management Studio and it complained about invalid column names.
What I simply did is create a new query, copy paste the SQL code from the old query to this new query and run it again. This seemed to refresh the environment correctly.
In my case I was trying to get the value from wrong ResultSet when querying multiple SQL statements.
In my case it seems the problem was a weird caching problem. The solutions above didn't work.
If your code was working fine and you added a column to one of your tables and it gives the 'invalid column name' error, and the solutions above doesn't work, try this: First run only the section of code for creating that modified table and then run the whole code.
Including this answer because this was the top result for "invalid column name sql" on google and I didn't see this answer here. In my case, I was getting Invalid Column Name, Id1 because I had used the wrong id in my .HasForeignKey statement in my Entity Framework C# code. Once I changed it to match the .HasOne() object's id, the error was gone.
I've gotten this error when running a scalar function using a table value, but the Select statement in my scalar function RETURN clause was missing the "FROM table" portion. :facepalms:
Also happens when you forget to change the ConnectionString and ask a table that has no idea about the changes you're making locally.
I had this problem with a View, but the exact same SQL code worked perfectly as a query. In fact SSMS actually threw up a couple of other problems with the View, that it did not have with the query. I tried refreshing, closing the connection to the server and going back in, and renaming columns - nothing worked. Instead I created the query as a stored procedure, and connected Excel to that rather than the View, and this solved the problem.