Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Getting different answer while using PARSENAME #2204

aksajith opened this issue May 24, 2019 · 3 comments


None yet
5 participants
Copy link

commented May 24, 2019

When i am trying the below query, getting different answers.
DECLARE @num2 decimal(26,10) = 152.00685100 SELECT PARSENAME(@num2,1) --- Output : 0068510000 SELECT PARSENAME(cast(@num2 as DOUBLE PRECISION),1) ---- Output : 007

what is the difference in these query. What is doing in depth.
I just try to convert to NVARCHAR/VARCHAR and try. that also getting different result

Document Details

Do not edit this section. It is required for ➟ GitHub issue linking.


This comment has been minimized.

Copy link

commented May 26, 2019

@aksajith This issue has nothing to do with PARSENAME. You are passing in numbers to a function which accepts a string input parameter. The difference in what you are seeing is happening in the implicit conversion from the particular number type into NVARCHAR. You can see this more clearly if you remove PARSENAME and just do the conversion explicitly:

DECLARE @num3 decimal(26,10) = 152.00685100;

SELECT CONVERT(NVARCHAR(500), @num3), -- 152.0068510000
       CONVERT(NVARCHAR(500), CONVERT(FLOAT, @num3)), -- 152.007
       STR(@num3, 18, 10); --     152.0068510000

You might also want to check out the STR built-in function, as it converts number types into VARCHAR.

Also, I highly recommend using FLOAT instead of the synonym DOUBLE PRECISION as a lot of people might not immediately know that "DOUBLE PRECISION" == FLOAT. In almost 20 years of using SQL Server, I have never once seen someone use DOUBLE PRECISION (not in code, or a book, blog post, article, forum, chat room, etc).

Take care, Solomon..

(cc @CarlRabeler and @MikeRayMSFT )


This comment has been minimized.

Copy link

commented May 30, 2019

@aksajith thank you for the question.
@srutzky thank you for the response.
I'm checking to see if we can clarify this in the documentation a bit.


This comment has been minimized.

Copy link

commented May 30, 2019

@MikeRayMSFT You are welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.