Getting Started with Adobe After Effects - Part 6: Motion Blur


Upload Image Close it
Select File

I hail from Chennai and hold a Masters degree in Computer Applications. I am into IT for more than a decade now. Presently, I model the role of a Senior Project Manager with Verizon Data Services India Pvt. Ltd., I have been MVP in SQL Server (2006-08, 2012) & .NET (2003-04).
Browse by Tags · View All
SQL Server 4
SSMS 2
Alter to 1
Data length 1
Bad Practice 1
BIGINT 1

Archive · View All
July 2012 4

Vadivel's (We)blog

Beware of Silent truncation of data in SQL Server

Jul 9 2012 12:00AM by Vadivel   

Do you find anything wrong with this script?

    CREATE PROCEDURE uspProcedureName
          @param1 VARCHAR
    AS
    ....
    ....
    
If you aren't sure may be you should read this post completely without fail :) 

All this while I was thinking that it is a well known issue until last week I saw a stored procedure something similar to the one shown above. Who ever created that stored procedure hasn't bothered to specify the length. Before jumping into the explanation of why we should SPECIFY THE LENGTH ALWAYS let us do a small exercise to understand this better. 

Guess the results: 

Try to answer what would be the output before checking the result.
    --Declaring a variable without specifying the length
    DECLARE @strSentence VARCHAR
    SET @strSentence = 'Rajinikanth is always the NO 1 hero of India'
    SELECT @strSentence
    
Expected Output: Rajinikanth is always the NO 1 hero of India 
Actual Output: R

 
    --While CASTing / CONVERTing
    --The given string has 36 characters.
    SELECT CONVERT(VARCHAR, '123456789123456789123456789123456789');
    SELECT CAST('123456789123456789123456789123456789' AS VARCHAR);
    
Expected Output: 123456789123456789123456789123456789 
Actual Output: 123456789123456789123456789123 

As you could see for Variables the default length for VARCHAR is 1. When used within CONVERT/CAST the default length for VARCHAR is 30. 

So if we don't specify the length ourself these are the default values SQL Server uses - which means the data what we would be expecting to get stored in the database would have got silently truncated without our knowledge. These are one such tricky issues which if we aren't aware would mean we have to spend hell a lot of time debugging our scripts at a later stage. Now to answer the first question on what is wrong with this script let us create a sample table and a stored procedure similar to that and see what it does.

    --Sample table
    CREATE TABLE dbo.tblDemo
    (
         ID INT,
         FirstName VARCHAR(30)
    )
    GO
    
    --Stored Procedure to Insert data into the sample table
    CREATE PROCEDURE dbo.uspInsertData
         @ID INT,
         @FName VARCHAR -- See there is no length specified here
    AS
    BEGIN
        SET NOCOUNT ON;
        INSERT INTO dbo.tblDemo VALUES (@ID, @FName)
    END
    GO
    
    --Test
    EXEC dbo.uspInsertData 10, 'Vadivel'
    GO
    SELECT ID, FirstName FROM dbo.tblDemo
    GO
    
The output would be just 'V'. Once again the data has got truncated silently. So ALWAYS SPECIFY THE LENGTH OF THE STRING WITHOUT FAIL.

    
    --Clean Up
    DROP PROC dbo.uspInsertData;
    DROP TABLE dbo.tblDemo;
    
Originally Posted here

Tags: SQL Server, Bad Practice, Data length


Vadivel
474 · 0% · 79
12
 
0
Lifesaver
 
 
 
0
Incorrect



Submit

10  Comments  

  • Very true. A few of my troubleshooting assignments ended up finding this as the culprit.

    commented on Jul 9 2012 11:43PM
    Jacob Sebastian
    1 · 100% · 32002
  • You may also need to read this Column Length and data length

    commented on Jul 9 2012 11:44PM
    Madhivanan
    3 · 39% · 12430
  • one more senario is when using ISNULL...

    ISNULL(arg1,arg2) -> return values datatype is same as datatype of arg1

    so if I write

    DECLARE @arg1 Varchar(2)=NULL

    DECLARE @arg1 Varchar(10)='satyajit'

    SELECT ISNULL(@arg1,@arg2)

    O/p will be 'sa' ..... So for me use of COALESCE is a better approach always as its return values datatype is set in accordance with highest datatype precedence

    for more detail ...

    http://beyondrelational.com/modules/2/blogs/381/posts/15549/the-null-dilemma-the-null-is-not-equal-to-null-part-2.aspx

    commented on Jul 10 2012 12:33AM
    satyajit
    124 · 1% · 402
  • This is in-fact triggering a very interesting discussion. Just wanted to add another silent killer that may have happened to many of us.

    DECLARE @a VARCHAR(MAX)
    
    SELECT @a = REPLICATE('a', 10000)
    SELECT LEN(@a) -- returns 8000
    
    SELECT @a = REPLICATE('a', 5000) + REPLICATE('a', 5000)
    SELECT LEN(@a) -- returns 8000
    

    Note that the string got truncated at 8000 though we would expect to get 10000 characters in the variable. Most common scenarios where this happened to me is when trying to build a huge dynamic query or building an email body from TSQL. To ensure that the strings are not truncated incorrectly, we need to make sure that at least one value involved in the string operation is of MAX data type so that the result is also a MAX value.

    For example:

    DECLARE @a VARCHAR(MAX) = ''
    SELECT @a = REPLICATE(CAST('a' AS VARCHAR(MAX)), 10000)
    SELECT LEN(@a) -- returns 10,000
    
    commented on Jul 10 2012 1:12AM
    Jacob Sebastian
    1 · 100% · 32002
  • Jacob, Here is the one about it http://beyondrelational.com/blogs/madhivanan/archive/2008/07/15/varchar-max-datatype-and-replicate-function.aspx

    commented on Jul 10 2012 1:23AM
    Madhivanan
    3 · 39% · 12430
  • To ensure that the strings are not truncated incorrectly, we need to make sure that at least one value involved in the string operation is of MAX data type so that the result is also a MAX value.

    It comes down to the return type of the function. The MSDN documentation specifies the return type as:

    Returns the same type as string_expression.

    Remember that varchar(max) and varbinary(max) are BLOBs so are different types to varchar(n) and varbinary(n). You wouldn't consider char(n) the same type as varchar(n) would you? :)

    Moreover, this functionality isn't particular to the REPLICATE function. Consider the following:

    DECLARE @a varchar(5000);
    SELECT @a = REPLICATE('a', 5000);
    SELECT LEN(@a), LEN(@a + @a);
    

    Would you be surprised to learn that LEN(@a + @a) is 8,000? And it's not the LEN function which is truncating the input! @a + @a returns a string of just 8,000 characters, not 10,000. If you don't believe it, try creating a new table and allow sql to assign the appropriate type for @a+@a:

    DECLARE @a varchar(5000) = REPLICATE('a', 5000);
    SELECT @a + @a AS testType INTO testblob;
    -- check the type of the field created in object explorer or with the following:
    SELECT LEN(testType), DATALENGTH(testType) FROM testblob;
    DROP TABLE testblob;
    

    If that still surprises you, how about:

    DECLARE @i int = 2147483647; -- maximum value of signed int
    SELECT @i+1;
    

    which yields:

    Msg 8115, Level 16, State 2, Line 2
    Arithmetic overflow error converting expression to data type int.
    

    I hope this has hammered the point home. If it's left you more confused, it's probably a good thing as it's pointed out that you need to review your sql types :D

    commented on Jul 10 2012 5:35AM
    a.diniz
    310 · 0% · 137
  • Thanks for all those comments guys :) Btw forgive my ignorance is there a way to post images (from our box) within our blog post? I saw only an option which was asking for an image URL.

    commented on Jul 10 2012 8:53AM
    Vadivel
    474 · 0% · 79
  • @Vadivel,

    Currently uploading images are a two step process. If you are using windows live writer to publish your blog posts, then it is quite simple. But to upload an image directly when writing a post on the web site or when writing a comment, you will need a two step process to upload and use an image.

    If you have a blog (in your case you have), you can see a link 'images' on the top of the page which allows you to upload an image. After the image is uploaded, you can take the URL and use it in a post/comment etc.

    We are about to release a separate section at BR which allows a user to quickly upload an share an image/screen-shot etc. This will make the whole process much easier. In case you are interested to have an early look into it, let me know and I will send you the details.

    commented on Jul 12 2012 5:53AM
    Jacob Sebastian
    1 · 100% · 32002
  • As I always used length with varchar so not came to issue like this, but good to know this.

    commented on Jul 18 2012 6:48AM
    sk2000
    504 · 0% · 73

Your Comment


Sign Up or Login to post a comment.

"Beware of Silent truncation of data in SQL Server" rated 5 out of 5 by 12 readers
Beware of Silent truncation of data in SQL Server , 5.0 out of 5 based on 12 ratings
    Copyright © Rivera Informatic Private Ltd Contact us      Privacy Policy      Terms of use      Report Abuse      Advertising      [ZULU1097]