I have to store maximum of 5000 character in sql server. Which one I can use to achieve this?
Should I use,
nvarchar(5000);
or
nvarchar(max);
nvarchar has a maximum (declareable) length of 4000. So since you want to store more than 4000 characters, you will have to use nvarchar(max).
nchar and nvarchar on MSDN
Related
Wondering which data type to select for my SQL Server to store the sha512 password hash. (hashed value will always have fixed length)
declare #hashedPasswd varchar(max)
set #hashedPasswd = convert(varchar(max), HASHBYTES('SHA2_512', 'any password with any langth'), 1)
select len (#hashedPasswd)
always returns length of 130.
What is the best choice for datatype of the column?
Variants are nvarchar(max), nvarchar(130), varchar, char.
If I understand correctly, nvarchar is a waste of space in my case, because It will be only ASCII symbols in hashed value.
Please assist.
SHA2_512 is 64 bytes long and internaly a varbinary so I would suggest using this datatype instead.
For more safty I also would recommend to use an additional salt for password encryption and decryption. You can find a useful description here:
https://www.mssqltips.com/sqlservertip/4037/storing-passwords-in-a-secure-way-in-a-sql-server-database/
Best regards, Stephan
According to the documentation, hasbytes returns a varbinary therefore your data type is varbinary.
Your length of 130 is only because you are casting to a varchar and is an inefficient way to store it. From the documentation, sha512 returns 64 bytes, therefore your length required is 64.
declare #hashedPasswd varbinary(max)
set #hashedPasswd = HASHBYTES('SHA2_512', 'any password with any length')
select len (#hashedPasswd)
After executing a CREATE TABLE for a temporary table I was verifying that the size of the field fits what I need to use.
To my surprise, SQL Server (Azure SQL) is reporting that the table now has double the size. Why is this?
This is what I executed, in order:
CREATE TABLE #A ( Name NVARCHAR(500) not null )
EXEC tempdb..sp_help '#A'
An NVARCHAR column in SQL Server always stores every character with 2 bytes.
So if you're asking for 500 characters (at 2 bytes each), obviously this results in column size of 1000 bytes.
That's been like this in SQL Server forever - this isn't new or Azure specific.
NVARCHAR shows 2 bytes per character. So if the size is 500 it shows size as 1000. It is to store unicode format data.
I have a table with a column data type nvarchar(max), the column will have data more than 8000 characters.
mytext navarchar(max)
I want to calculate hash value of that column, I am using the following code in MS SQL 2008/R2
select HASHBYTES('md5',column_name)
But I am getting error as,
String or binary data would be truncated.
Is that possible to calculate hash value in nvarchar(max) field in sql query.
Or is there any other ways to do it.
Thanks in advance.
Allowed input values are limited to 8000 bytes as was mentioned.
Try:
select master.sys.fn_repl_hash_binary(cast(column_name as varbinary(max)))
For this operation you have to disable FIPS validated cryptographic algorithms:
http://blog.aggregatedintelligence.com/2007/10/fips-validated-cryptographic-algorithms.html
I have a SQL Stored procedure that sends a mail. It's signature looks like this:
CREATE PROCEDURE SendMail
#From varchar(40),
#To varchar(255),
#Subject varchar(255),
#Body varchar(max),
#CC varchar(255) = null,
#BCC varchar(255) = null
AS...
When the message is for example 5000 characters it work. When it is 12 000, I get an error that [ODBC SQL Server Driver]String data, right truncation.
According to the help files varchar(max) can handle 2^31-1 bytes / characters.
So I tried changing #Body varchar(max) to #Body varchar(30000) and I get an error that
The size (30000) given to the type 'varchar' exceeds the maximum allowed for any data type (8000).
So the max is 8000 and not 2^31-1 bytes?
How can I handle more than 8000 characters?
You need to use nvarchar(max), instead of varchar(4000) or varchar(max). This can store up to 2 GB of text, which will solve your problem...
For more information see http://technet.microsoft.com/en-us/library/ms186939.aspx
Text fields cannot be larger than 8060 Bytes (8K) due to SQL Server Page Size which is 8K...
varchar has a maximum #of chars of 8000
nvarchar has a maximum #of chars of 4000 (each char-->2 bytes)
You cannot declare a parameter varchar(30000)
You should use varchar(max) or nvarchar(max)
the first has 2^31 chars (approx 2billions), the latter has 2^30 chars (approx 1billion)
Also, please note that SQL Server has a Stored Proc Named sp_send_dbmail that you can use to sen emails...
Try using NVARCHAR(MAX) instead of VARCHAR(MAX).
Use the BLOB data type. I use it occasionally for very long fields but it cannot be compared. I do not believe there is a max length on BLOB.
Max. capacity is 2 GByte of space - so you're looking at just over 1 billion 2-byte characters that will fit into a NVARCHAR(MAX) field.
Using the other answer's more detailed numbers, you should be able to store
(2 ^ 31 - 1) / 2 = 1'037'741'823 double-byte characters
1 billion, 37 million, 741 thousand and 823 characters to be precise
in your NVARCHAR(MAX) column (unfortunately, that last half character is wasted...)
SOURCE
REPLICATE returns the input type irrespective of later assignment. It's annoying, but to avoid silent truncation, try this example:
declare #x varchar(max) set #x = replicate (cast('a' as varchar(max)),
10000) select #x, len(#x)
This is because SQL Server performs the REPLICATE operation before it considers what you're assigning it to or how many characters you're trying to expand it to. It only cares about the input expression to determine what it should return, and if the input is not a max type, it assumes it is meant to fit within 8,000 bytes.
Software I'm working with uses a text field to store XML. From my searches online, the text datatype is supposed to hold 2^31 - 1 characters. Currently SQL Server is truncating the XML at 65,535 characters every time. I know this is caused by SQL Server, because if I add a 65,536th character to the column directly in Management Studio, it states that it will not update because characters will be truncated.
Is the max length really 65,535 or could this be because the database was designed in an earlier version of SQL Server (2000) and it's using the legacy text datatype instead of 2005's?
If this is the case, will altering the datatype to Text in SQL Server 2005 fix this issue?
that is a limitation of SSMS not of the text field, but you should use varchar(max) since text is deprecated
Here is also a quick test
create table TestLen (bla text)
insert TestLen values (replicate(convert(varchar(max),'a'), 100000))
select datalength(bla)
from TestLen
Returns 100000 for me
MSSQL 2000 should allow up to 2^31 - 1 characters (non unicode) in a text field, which is over 2 billion. Don't know what's causing this limitation but you might wanna try using varchar(max) or nvarchar(max). These store as many characters but allow also the regular string T-SQL functions (like LEN, SUBSTRING, REPLACE, RTRIM,...).
If you're able to convert the column, you might as well, since the text data type will be removed in a future version of SQL Server. See here.
The recommendation is to use varchar(MAX) or nvarchar(MAX). In your case, you could also use the XML data type, but that may tie you to certain database engines (if that's a consideration).
You should have a look at
XML Support in Microsoft SQL Server
2005
Beginning SQL Server 2005 XML
Programming
So I would rather try to use the data type appropriate for the use. Not make a datatype fit your use from a previous version.
Here's a little script I wrote for getting out all data
SELECT #data = N'huge data';
DECLARE #readSentence NVARCHAR (MAX) = N'';
DECLARE #dataLength INT = ( SELECT LEN (#data));
DECLARE #currIndex INT = 0;
WHILE #data <> #readSentence
BEGIN
DECLARE #temp NVARCHAR (MAX) = N'';
SET #temp = ( SELECT SUBSTRING (#data, #currIndex, 65535));
SELECT #temp;
SET #readSentence += #temp;
SET #currIndex += 65535;
END;