December 2, 2009 at 10:18 am
Hello experts
I have a numeric(9,4) columnA and the users need an output like below.
COLUMNA Modifier RESULT
1234.5678 10000 12345678
1.8 10 18
0.6750 10000 6750
The result * modifier should give the original values (column A)
Thx
Kalyan
December 2, 2009 at 10:57 am
you can select the results of any calculation as a column in your query.
SELECT
COLUMNA ,
Modifier,
(COLUMNA * Modifier) As Result
from MyTable
Lowell
December 2, 2009 at 11:33 am
I must state my request clearly:(
The columns Modifier and result are not in the table,I need to create those as output.
The table only has ColumnA.
Basically given any input with upto 4 decimal places I need an output without decimal and a modifier which can be applied to the RESULT to get back the original ColumnA values.
If ColumnA has 7.89,I need RESULT=789(i.e without decimal) and a modifier = 100 and hence to get ColumnA I do RESULT/Modifier=789/100=7.89.
HTH
December 2, 2009 at 12:07 pm
kalyan sankar
I have a numeric(9,4) columnA
If you insert 7.89 / 1.8 into a numeric(9,4) column they will exist in the table as 7.8900 / 1.800
CREATE TABLE #T(ColumnA Numeric(9,4))
INSERT INTO #T
SELECT 1234.5678 UNION ALL
SELECT 1.8 UNION ALL --as specified in your original post
SELECT 0.6750 UNION ALL --as specified in your original post
SELECT 7.89 --as specified in your 2nd posting
SELECT * FROM #T
Tables contents
ColumnA
1234.5678
1.8000
0.6750
7.8900
Do I understand that you want the trailing 0 on 0.6750 to remain, but the trailing 00 to be trimed from the 7.89 input? Or all trailing zeroes to be removed?
Also
are these values to be used in another mathematical operation or would displaying them as VARCHAR be acceptable?
December 2, 2009 at 1:48 pm
Trailing zeroes are fine and the output will be in VARCHAR columns
December 2, 2009 at 1:48 pm
kalyan sankar (12/2/2009)
I must state my request clearly:(The columns Modifier and result are not in the table,I need to create those as output.
The table only has ColumnA.
Basically given any input with upto 4 decimal places I need an output without decimal and a modifier which can be applied to the RESULT to get back the original ColumnA values.
If ColumnA has 7.89,I need RESULT=789(i.e without decimal) and a modifier = 100 and hence to get ColumnA I do RESULT/Modifier=789/100=7.89.
HTH
You did well in stating your request and it's a piece-o-cake... 😉
--COLUMNA Modifier RESULT
--1234.5678 10000 12345678
--1.8 10 18
--0.6750 10000 6750
--===== Create a test table from the original posting.
-- This is NOT a part of the solution
DECLARE @t TABLE (ColumnA DECIMAL(9,4))
INSERT INTO @t (ColumnA)
SELECT 1234.5678 UNION ALL
SELECT 1.8 UNION ALL
SELECT 0.6750
--===== Show what's in the test table.
-- Again, this is NOT a part of the solution.
SELECT * FROM @t
--===== Now, solve the problem easily by using CTE's to peel one potato at a time...
;WITH
cteTrim
AS ( --=== Determine how many significant digits to right of decimal point
SELECT ColumnA,
Trimmed = RTRIM(REPLACE(CAST(ColumnA AS VARCHAR(10)),'0',' '))
FROM @t)
,
cteModifier
AS ( --=== From the above, determine what the modifier is
SELECT ColumnA,
Modifier = POWER(10,LEN(Trimmed)-CHARINDEX('.',Trimmed))
FROM cteTrim)
--===== From that, determine the final output
SELECT ColumnA,
Modifier,
Result = CAST(ColumnA*Modifier AS BIGINT)
FROM cteModifier;
Results...
ColumnAModifierResult
1234.56781000012345678
1.80001018
0.67501000675
--Jeff Moden
Change is inevitable... Change for the better is not.
December 2, 2009 at 2:08 pm
Nice one Jeff,
Once again, you've proven we don't need RBAR code to solve even a format problem for SQL.
Keep it up, love to learn from you,
Cheers,
J-F
December 2, 2009 at 6:03 pm
J-F Bergeron (12/2/2009)
Nice one Jeff,Once again, you've proven we don't need RBAR code to solve even a format problem for SQL.
Keep it up, love to learn from you,
You've made my day, J-F. Thank you for the feedback!
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2009 at 7:11 am
Nice solution, but not entirely correct, I think. What about non-trailing zeroes behind the decimal point i.e. 1234.5078. The result is Modifier=1000, Result=1234507. I little fix will do:
SELECT ColumnA,
Trimmed = REPLACE(RTRIM(REPLACE(CAST(ColumnA AS VARCHAR(10)), '0', ' ')), ' ', '0')
But maybe that was Jeff's intention already (because of the RTRIM in the initial solution).
Peter
December 3, 2009 at 7:35 am
Thank you all very much.
That works for me and we will surely be using and testing the code in our application.
Did I mention This is the best support forum:-D:-D
December 3, 2009 at 8:40 am
Peter Brinkhaus (12/3/2009)
Nice solution, but not entirely correct, I think. What about non-trailing zeroes behind the decimal point i.e. 1234.5078. The result is Modifier=1000, Result=1234507. I little fix will do:
SELECT ColumnA,
Trimmed = REPLACE(RTRIM(REPLACE(CAST(ColumnA AS VARCHAR(10)), '0', ' ')), ' ', '0')
But maybe that was Jeff's intention already (because of the RTRIM in the initial solution).
Peter
That last part is correct. The intent of the first CTE in my example has nothing to do with producing the correct number on the first pass. The only purpose was to find the last significant digit so we can count the number of places past the decimal point. That number of places was then used to figure out the necessary power of 10 to create the multiplier for. Because the CTE's "reflect" back into each other, it makes for some very high speed code that's also easy to read/debug because of the Divide'n'Conquer nature of the code.
I'll take a look and see where I mucked up on the embedded zero.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2009 at 8:47 am
Ah... now I see. Somewhere along the line, a space in quotes got dropped when I transferred the code to the forum window. I've edited the previous code to be correct.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 3, 2009 at 8:57 am
Now I see too. Replacing the spaces back to zeroes after trimming isn't necessary as the Trimmed value is only used to determine the number of digits behind the decimal point. Again, nice solution.
Peter
December 3, 2009 at 11:59 am
Jeff Moden (12/3/2009)
Ah... now I see. Somewhere along the line, a space in quotes got dropped when I transferred the code to the forum window. I've edited the previous code to be correct.
Just another thought. Wouldn't it be a better idea to publish the modified code in a new post (even if the change is just a single space)? In general, I think, threads will become hard to follow when people start to edit their posts based on comments in other posts within the same thread.
Peter
December 3, 2009 at 2:14 pm
I thought of doing that, as well. But if someone stops at the first post (as so often happens), they'd have bad code.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 18 total)
You must be logged in to reply to this topic. Login to reply