Related
I am trying to insert some text data into a table in SQL Server 9.
The text includes a single quote '.
How do I escape that?
I tried using two single quotes, but it threw me some errors.
eg. insert into my_table values('hi, my name''s tim.');
Single quotes are escaped by doubling them up, just as you've shown us in your example. The following SQL illustrates this functionality. I tested it on SQL Server 2008:
DECLARE #my_table TABLE (
[value] VARCHAR(200)
)
INSERT INTO #my_table VALUES ('hi, my name''s tim.')
SELECT * FROM #my_table
Results
value
==================
hi, my name's tim.
If escaping your single quote with another single quote isn't working for you (like it didn't for one of my recent REPLACE() queries), you can use SET QUOTED_IDENTIFIER OFF before your query, then SET QUOTED_IDENTIFIER ON after your query.
For example
SET QUOTED_IDENTIFIER OFF;
UPDATE TABLE SET NAME = REPLACE(NAME, "'S", "S");
SET QUOTED_IDENTIFIER ON;
-- set OFF then ON again
How about:
insert into my_table values('hi, my name' + char(39) + 's tim.')
Many of us know that the Popular Method of Escaping Single Quotes is by Doubling them up easily like below.
PRINT 'It''s me, Arul.';
we are going to look on some other alternate ways of escaping the single quotes.
1. UNICODE Characters
39 is the UNICODE character of Single Quote. So we can use it like below.
PRINT 'Hi,it'+CHAR(39)+'s Arul.';
PRINT 'Helo,it'+NCHAR(39)+'s Arul.';
2. QUOTED_IDENTIFIER
Another simple and best alternate solution is to use QUOTED_IDENTIFIER.
When QUOTED_IDENTIFIER is set to OFF, the strings can be enclosed in double quotes.
In this scenario, we don’t need to escape single quotes.
So,this way would be very helpful while using lot of string values with single quotes.
It will be very much helpful while using so many lines of INSERT/UPDATE scripts where column values having single quotes.
SET QUOTED_IDENTIFIER OFF;
PRINT "It's Arul."
SET QUOTED_IDENTIFIER ON;
CONCLUSION
The above mentioned methods are applicable to both AZURE and On Premises .
2 ways to work around this:
for ' you can simply double it in the string, e.g.
select 'I''m happpy' -- will get: I'm happy
For any charactor you are not sure of: in sql server you can get any char's unicode by select unicode(':') (you keep the number)
So this case you can also select 'I'+nchar(39)+'m happpy'
The doubling up of the quote should have worked, so it's peculiar that it didn't work for you; however, an alternative is using double quote characters, instead of single ones, around the string. I.e.,
insert into my_table values("hi, my name's tim.");
Also another thing to be careful of is whether or not it is really stored as a classic ASCII ' (ASCII 27) or Unicode 2019 (which looks similar, but not the same). This isn't a big deal on inserts, but it can mean the world on selects and updates. If it's the unicode value then escaping the ' in a WHERE clause (e.g where blah = 'Workers''s Comp') will return like the value you are searching for isn't there if the ' in "Worker's Comp" is actually the unicode value.If your client application supports free-key, as well as copy and paste based input, it could be Unicode in some rows, and ASCII in others!
A simple way to confirm this is by doing some kind of open ended query that will bring back the value you are searching for, and then copy and paste that into notepad++ or some other unicode supporting editor. The differing appearance between the ascii value and the unicode one should be obvious to the eyes, but if you lean towards the anal, it will show up as 27 (ascii) or 92 (unicode) in a hex editor.
The following syntax will escape you ONLY ONE quotation mark:
SELECT ''''
The result will be a single quote. Might be very helpful for creating dynamic SQL :).
Double quotes option helped me
SET QUOTED_IDENTIFIER OFF;
insert into my_table values("hi, my name's tim.");
SET QUOTED_IDENTIFIER ON;
This should work
DECLARE #singleQuote CHAR
SET #singleQuote = CHAR(39)
insert into my_table values('hi, my name'+ #singleQuote +'s tim.')
Just insert a ' before anything to be inserted. It will be like a escape character in sqlServer
Example:
When you have a field as, I'm fine.
you can do:
UPDATE my_table SET row ='I''m fine.';
I had the same problem, but mine was not based of static data in the SQL code itself, but from values in the data.
This code lists all the columns names and data types in my database:
SELECT DISTINCT QUOTENAME(COLUMN_NAME),DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS
But some column names actually have a single-quote embedded in the name of the column!, such as ...
[MyTable].[LEOS'DATACOLUMN]
To process these, I had to use the REPLACE function along with the suggested QUOTED_IDENTIFIER setting. Otherwise it would be a syntax error, when the column is used in a dynamic SQL.
SET QUOTED_IDENTIFIER OFF;
SET #sql = 'SELECT DISTINCT ''' + #TableName + ''',''' + REPLACE(#ColumnName,"'","''") + ...etc
SET QUOTED_IDENTIFIER ON;
The STRING_ESCAPE funtion can be used on newer versions of SQL Server
This should work: use a back slash and put a double quote
"UPDATE my_table SET row =\"hi, my name's tim.\";
How can I make a query to see if any record have the value (')?
I have tried this:
Select * from table where column LIKE '%'%' and other variants and still get sintax error.
And i have the same problem when I do a query like:
Select * from table where column == 'hello'world'
I have in the database a record stored with hello'world
I guess that bot questions have the same answer.
You just have to escape it by using the single quote twice (''), It will be considered as the single quote rather than the starting/ending of the string as follows:
Select * from table where column LIKE '%''%'
You can also use the QUOTED_IDENTIFIER:
According to documentation, When QUOTED_IDENTIFIER is OFF, Literals can
be delimited by either single or double quotation marks. If a literal
string is delimited by double quotation marks, the string can contain
embedded single quotation marks, such as apostrophes.
You can use it as follows:
SET QUOTED_IDENTIFIER OFF;
Select * from table where column LIKE "%'%"
SET QUOTED_IDENTIFIER ON;
' has to be doubled:
Select * from tab where col LIKE '%''%'
I am trying to insert some text data into a table in SQL Server 9.
The text includes a single quote '.
How do I escape that?
I tried using two single quotes, but it threw me some errors.
eg. insert into my_table values('hi, my name''s tim.');
Single quotes are escaped by doubling them up, just as you've shown us in your example. The following SQL illustrates this functionality. I tested it on SQL Server 2008:
DECLARE #my_table TABLE (
[value] VARCHAR(200)
)
INSERT INTO #my_table VALUES ('hi, my name''s tim.')
SELECT * FROM #my_table
Results
value
==================
hi, my name's tim.
If escaping your single quote with another single quote isn't working for you (like it didn't for one of my recent REPLACE() queries), you can use SET QUOTED_IDENTIFIER OFF before your query, then SET QUOTED_IDENTIFIER ON after your query.
For example
SET QUOTED_IDENTIFIER OFF;
UPDATE TABLE SET NAME = REPLACE(NAME, "'S", "S");
SET QUOTED_IDENTIFIER ON;
-- set OFF then ON again
How about:
insert into my_table values('hi, my name' + char(39) + 's tim.')
Many of us know that the Popular Method of Escaping Single Quotes is by Doubling them up easily like below.
PRINT 'It''s me, Arul.';
we are going to look on some other alternate ways of escaping the single quotes.
1. UNICODE Characters
39 is the UNICODE character of Single Quote. So we can use it like below.
PRINT 'Hi,it'+CHAR(39)+'s Arul.';
PRINT 'Helo,it'+NCHAR(39)+'s Arul.';
2. QUOTED_IDENTIFIER
Another simple and best alternate solution is to use QUOTED_IDENTIFIER.
When QUOTED_IDENTIFIER is set to OFF, the strings can be enclosed in double quotes.
In this scenario, we don’t need to escape single quotes.
So,this way would be very helpful while using lot of string values with single quotes.
It will be very much helpful while using so many lines of INSERT/UPDATE scripts where column values having single quotes.
SET QUOTED_IDENTIFIER OFF;
PRINT "It's Arul."
SET QUOTED_IDENTIFIER ON;
CONCLUSION
The above mentioned methods are applicable to both AZURE and On Premises .
2 ways to work around this:
for ' you can simply double it in the string, e.g.
select 'I''m happpy' -- will get: I'm happy
For any charactor you are not sure of: in sql server you can get any char's unicode by select unicode(':') (you keep the number)
So this case you can also select 'I'+nchar(39)+'m happpy'
The doubling up of the quote should have worked, so it's peculiar that it didn't work for you; however, an alternative is using double quote characters, instead of single ones, around the string. I.e.,
insert into my_table values("hi, my name's tim.");
Also another thing to be careful of is whether or not it is really stored as a classic ASCII ' (ASCII 27) or Unicode 2019 (which looks similar, but not the same). This isn't a big deal on inserts, but it can mean the world on selects and updates. If it's the unicode value then escaping the ' in a WHERE clause (e.g where blah = 'Workers''s Comp') will return like the value you are searching for isn't there if the ' in "Worker's Comp" is actually the unicode value.If your client application supports free-key, as well as copy and paste based input, it could be Unicode in some rows, and ASCII in others!
A simple way to confirm this is by doing some kind of open ended query that will bring back the value you are searching for, and then copy and paste that into notepad++ or some other unicode supporting editor. The differing appearance between the ascii value and the unicode one should be obvious to the eyes, but if you lean towards the anal, it will show up as 27 (ascii) or 92 (unicode) in a hex editor.
The following syntax will escape you ONLY ONE quotation mark:
SELECT ''''
The result will be a single quote. Might be very helpful for creating dynamic SQL :).
Double quotes option helped me
SET QUOTED_IDENTIFIER OFF;
insert into my_table values("hi, my name's tim.");
SET QUOTED_IDENTIFIER ON;
This should work
DECLARE #singleQuote CHAR
SET #singleQuote = CHAR(39)
insert into my_table values('hi, my name'+ #singleQuote +'s tim.')
Just insert a ' before anything to be inserted. It will be like a escape character in sqlServer
Example:
When you have a field as, I'm fine.
you can do:
UPDATE my_table SET row ='I''m fine.';
I had the same problem, but mine was not based of static data in the SQL code itself, but from values in the data.
This code lists all the columns names and data types in my database:
SELECT DISTINCT QUOTENAME(COLUMN_NAME),DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS
But some column names actually have a single-quote embedded in the name of the column!, such as ...
[MyTable].[LEOS'DATACOLUMN]
To process these, I had to use the REPLACE function along with the suggested QUOTED_IDENTIFIER setting. Otherwise it would be a syntax error, when the column is used in a dynamic SQL.
SET QUOTED_IDENTIFIER OFF;
SET #sql = 'SELECT DISTINCT ''' + #TableName + ''',''' + REPLACE(#ColumnName,"'","''") + ...etc
SET QUOTED_IDENTIFIER ON;
The STRING_ESCAPE funtion can be used on newer versions of SQL Server
This should work: use a back slash and put a double quote
"UPDATE my_table SET row =\"hi, my name's tim.\";
NOTE: I checked Understanding QUOTED_IDENTIFIER and it does not answer my question.
I got my DBAs to run an index I made on my Prod servers (they looked it over and approved it).
It sped up my queries just like I wanted. However, I started getting errors like this:
As a developer I have usually ignored these settings. And it has never mattered. (For 9+ years). Well, today it matters.
I went and looked at one of the sprocs that are failing and it has this before the create for the sproc:
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
Can anyone tell me from a application developer point of view what these set statements do? (Just adding the above code before my index create statements did not fix the problem.)
NOTE: Here is an example of what my indexes looked like:
CREATE NONCLUSTERED INDEX [ix_ClientFilerTo0]
ON [ClientTable] ([Client])
INCLUDE ([ClientCol1],[ClientCol2],[ClientCol3] ... Many more columns)
WHERE Client = 0
CREATE NONCLUSTERED INDEX [IX_Client_Status]
ON [OrderTable] ([Client],[Status])
INCLUDE ([OrderCol1],[OrderCol2],[OrderCol3],[OrderCol4])
WHERE [Status] <= 7
GO
OK, from an application developer's point of view, here's what these settings do:
QUOTED_IDENTIFIER
This setting controls how quotation marks ".." are interpreted by the SQL compiler. When QUOTED_IDENTIFIER is ON then quotes are treated like brackets ([...]) and can be used to quote SQL object names like table names, column names, etc. When it is OFF (not recommended), then quotes are treated like apostrophes ('..') and can be used to quote text strings in SQL commands.
ANSI_NULLS
This setting controls what happens when you try to use any comparison operator other than IS on NULL. When it is ON, these comparisons follow the standard which says that comparing to NULL always fails (because it isn't a value, it's a Flag) and returns FALSE. When this setting is OFF (really not recommended) you can sucessfully treat it like a value and use =, <>, etc. on it and get back TRUE as appropiate.
The proper way to handle this is to instead use the IS (ColumnValue IS NULL ..).
CONCAT_NULL_YIELDS_NULL
This setting controls whether NULLs "Propogate" whn used in string expressions. When this setting is ON, it follows the standard and an expression like 'some string' + NULL .. always returns NULL. Thus, in a series of string concatenations, one NULL can cause the whole expression to return NULL. Turning this OFF (also, not recommended) will cause the NULLs to be treated like empty strings instead, so 'some string' + NULL just evaluates to 'some string'.
The proper way to handle this is with the COALESCE (or ISNULL) function: 'some string' + COALESCE(NULL, '') ...
I find the documentation, blog posts, Stackoverflow answers unhelpful in explaining what turning on QUOTED_IDENTIFIER means.
Olden times
Originally, SQL Server allowed you to use quotation marks ("...") and apostrophes ('...') around strings interchangeably (like Javascript does):
SELECT "Hello, world!" --quotation mark
SELECT 'Hello, world!' --apostrophe
And if you wanted a name table, view, procedure, column etc with something that would otherwise violate all the rules of naming objects, you could wrap it in square brackets ([, ]):
CREATE TABLE [The world's most awful table name] (
[Hello, world!] int
)
SELECT [Hello, world!] FROM [The world's most awful table name]
And that all worked, and made sense.
Then came ANSI
Then ANSI came along and had other ideas:
use apostrophe ('...') for strings
if you have a funky name, wrap it in quotation marks ("...")
and we don't even care about your square brackets
Which means that if you wanted to "quote" a funky column or table name you must use quotation marks:
SELECT "Hello, world!" FROM "The world's most awful table name"
If you knew SQL Server, you knew that quotation marks were already being used to represent strings. If you blindly tried to execute that ANSI-SQL as if it were T-SQL, it is nonsense:
SELECT 'Hello, world!' FROM 'The world''s most awful table name'
and SQL Server tells you so:
Msg 102, Level 15, State 1, Line 8
Incorrect syntax near 'The world's most awful table name'.
You must opt-in to the new ANSI behavior
So Microsoft added a feature to let you opt-in to the ANSI flavor of SQL.
Original (aka SET QUOTED_IDENTIFIER OFF)
SELECT "Hello, world!" --valid
SELECT 'Hello, world!' --valid
SET QUOTED_IDENTIFIER ON
SELECT "Hello, world!" --INVALID
SELECT 'Hello, world!' --valid
These days everyone has SET QUOTED_IDENTIFIERS ON, which technically means you should be using quotes rather than square brackets around identifiers:
T-SQL (bad?) (e.g. SQL generated by Entity Framework)
UPDATE [dbo].[Customers]
SET [FirstName] = N'Ian'
WHERE [CustomerID] = 7
ANSI-SQL (good?)
UPDATE "dbo"."Customers"
SET "FirstName" = N'Ian'
WHERE "CustomerID" = 7
In reality nobody in the SQL Server universe uses U+0022 QUOTATION MARK " to wrap identifiers. We all continue to use [].
I think while rebuilding the indexes it got turned off.
Do check the SET Options with their setting values required while working with filtered index
You need to turn On the below setting while dealing with filtered index:
SET ANSI_NULLS ON
SET ANSI_PADDING ON
SET ANSI_WARNINGS ON
SET ARITHABORT ON
SET CONCAT_NULL_YIELDS_NULL ON
SET QUOTED_IDENTIFIER ON
You need add to add
SET ANSI_NULLS, QUOTED_IDENTIFIER ON
for all my stored procedures editing a table with a computed column to avoid that error.
ANSI_NULLS:
When SET ANSI_NULLS is ON, a SELECT statement that uses WHERE
column_name = NULL returns zero rows even if there are null values in
column_name. A SELECT statement that uses WHERE column_name <> NULL
returns zero rows even if there are nonnull values in column_name.
When SET ANSI_NULLS is OFF, the Equals (=) and Not Equal To (<>)
comparison operators do not follow the ISO standard. A SELECT
statement that uses WHERE column_name = NULL returns the rows that
have null values in column_name. A SELECT statement that uses WHERE
column_name <> NULL returns the rows that have nonnull values in the
column. Also, a SELECT statement that uses WHERE column_name <>
XYZ_value returns all rows that are not XYZ_value and that are not
NULL.
QUOTED_IDENTIFIER
When SET QUOTED_IDENTIFIER is ON, identifiers can be delimited by
double quotation marks, and literals must be delimited by single
quotation marks. When SET QUOTED_IDENTIFIER is OFF, identifiers cannot
be quoted and must follow all Transact-SQL rules for identifiers. For
more information, see Database Identifiers. Literals can be delimited
by either single or double quotation marks.
When SET QUOTED_IDENTIFIER is ON (default), all strings delimited by
double quotation marks are interpreted as object identifiers.
Therefore, quoted identifiers do not have to follow the Transact-SQL
rules for identifiers. They can be reserved keywords and can include
characters not generally allowed in Transact-SQL identifiers. Double
quotation marks cannot be used to delimit literal string expressions;
single quotation marks must be used to enclose literal strings. If a
single quotation mark (') is part of the literal string, it can be
represented by two single quotation marks ("). SET QUOTED_IDENTIFIER
must be ON when reserved keywords are used for object names in the
database.
CONCAT_NULL_YIELDS_NULL
When SET CONCAT_NULL_YIELDS_NULL is ON, concatenating a null value
with a string yields a NULL result. For example, SELECT 'abc' + NULL
yields NULL. When SET CONCAT_NULL_YIELDS_NULL is OFF, concatenating a
null value with a string yields the string itself (the null value is
treated as an empty string). For example, SELECT 'abc' + NULL yields
abc.
If SET CONCAT_NULL_YIELDS_NULL is not specified, the setting of the
CONCAT_NULL_YIELDS_NULL database option applies.
ANSI_NULLS ON makes any binary boolean expression with a null value evaluate to false. Using the following template:
declare #varA, #varB int
if <binary boolean expression>
begin
print 'true'
end
else
begin
print 'false'
end
#varA: NULL; #varB: NULL; #varA = #varB evaluates to false
#varA: 1; #varB: NULL; #varA <> #varB evaluates to false
The proper way to test for null is to use is [not] NULL
#varA: NULL; #varA is NULL evaluates to true
#varA: 1; #varA is not NULL evaluates to true
QUOTED_IDENTIFER ON merely allows you to use double quotes to delimit identifiers (bad idea IMO, just user square brackets)
from tblA "a" -- ok when ON, not ok when OFF
from tblA [a] -- always ok
I'm working with MS SQL SERVER 2003. I want to change a column in one of my tables to have fewer characters in the entries. This is identical to this question: Altering a Table Column to Accept More Characters except for the fact that I want fewer characters instead of more.
I have a column in one of my tables that holds nine-digit entries. A developer previously working on the table mistakenly set the column to hold ten-digit entries. I need to change the type from CHAR(10) to CHAR(9).
Following the instructions from the discussion linked above, I wrote the statement
ALTER TABLE [MY_TABLE] ALTER COLUMN [MY_COLUMN] CHAR(9);
This returns the error message "String or binary data would be truncated". I see that my nine-digit strings have a space appended to make them ten digits.
How do I tell SQL Server to discard the extra space and convert my column to a CHAR(9) type?
I think you get the error because there are some values in that table that are exactly 10 chars long (with no trailing spaces). Altering the table would thus cut these values to the length 9.
This is not allowed by default. If there only would be strings which would have some trailing spaces, there would be no problem with that.
So, if you are ok with cutting those values, do
UPDATE MY_TABLE SET MY_COLUMN = LEFT(MY_COLUMN, 9)
first, after that do the alter.
Disable Ansi Warnings before you alter your table.
SET ANSI_WARNINGS OFF
Beware that data will be truncated if you happen to have something 10 characters long.
Edit
Check existing lengths before actually changing the column length.
SET ANSI_WARNINGS OFF
GO
CREATE TABLE Test (Value CHAR(10))
INSERT INTO Test SELECT ('1234567890')
IF NOT EXISTS (SELECT * FROM Test WHERE LEN(Value) > 9)
ALTER TABLE Test ALTER COLUMN Value CHAR(9)
ELSE
SELECT LEN(Value), * FROM Test WHERE LEN(Value) > 9
DROP TABLE Test
The above 2 answers didn't work for me because I had a history table attached to the table I was trying to alter. This is what I did:
UPDATE MY_TABLE SET MY_COLUMN = LEFT(MY_COLUMN, 9)
ALTER TABLE MY_TABLE SET (SYSTEM_VERSIONING = OFF)
-- Might need to UPDATE MY_TABLEHistory SET MY_COLUMN = LEFT(MY_COLUMN, 9)
-- I didn't
ALTER TABLE MY_TABLEHistory ALTER COLUMN [MY_COLUMN] [varchar] (9) NULL
ALTER TABLE MY_TABLE SET (SYSTEM_VERSIONING = ON(HISTORY_TABLE = MY_TABLEHistory))
ALTER TABLE MY_TABLE ALTER COLUMN [MY_COLUMN] [varchar] (9) NULL