InstantForum.NET v2.9.0SQLServerCentralhttp://www.sqlservercentral.com/Forums/notifications@sqlservercentral.comSun, 19 May 2013 09:13:18 GMT20http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]Duncan Pryde (3/20/2011)[/b][hr][quote][b]bitbucket-25253 (3/20/2011)[/b][hr]Excellent question and a more than excellent explanation of why the correct answer is what it is.[/quote]Thanks - high praise indeed! I must mention though, that when trying to decide how to format the explanation, I came across [url=http://www.sqlservercentral.com/Forums/FindPost870258.aspx]this excellent post[/url] from SQL Kiwi (Paul White?) - which helped me considerably to come up with a clearer and more concise one than I would have done otherwise.:cool:[/quote]Yes, that's me. :-)Sun, 26 Jun 2011 04:40:56 GMTPaul Whitehttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]michael.kaufmann (3/21/2011)[/b][hr][quote][b]tilew-948340 (3/20/2011)[/b][hr]I am sorry, but I realy, realy don't understand why D is not good, even if I do your formula. Why is so that D would have a truncate answer and not C? I mean, both have a precision of 51 and only the scale is different (3 more digit more for C), which might explain something if you could explain my question here:If I declare D as precision of 23 instead of 25 and still having a scale of 10DECLARE @value1D DECIMAL(23,10), @value2D DECIMAL(23,10)it is still a precision over 38, and the scale is still 20 as previous, but the answer is not truncateWhy??? :crazy:[/quote]First of all a great big thank you to Duncan for this excellent QotD and the explanation.Whether the decimal result is 'truncated' or not is a mere mathematical question:D would result in precision 51 and scale 20; in order to not truncate the integer part of the numeral, SQL Server does the following:- maximum precision = 38, desired precision is 51 ==> 51 - 38 = 13- since it doesn't truncate the integer part, the decimal portion (scale) is truncated: 20 - 13 = 7.Hence the result for option D is DECIMAL(38,7).If you use a precsion of 23, the math is as follows:- Precision: 47 - 38 = 9- Scale: 20 - 9 = 11- Result: DECIMAL(38,11)However, as Duncan stated in his explanation, scale will never be less than 6; so the 'minimum' result in regards to scale will always be DECIMAL (38,6).Regards,Michael[/quote]Nice question! And this is an excellent explanation.Wed, 25 May 2011 01:09:38 GMThakan.wintherhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxInteresting question and a great explanation.I learned something, although i got it wrong :)!Fri, 01 Apr 2011 00:16:13 GMTanders-731262http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]cengland0 (3/22/2011)[/b][hr][quote][b]SanDroid (3/22/2011)[/b][hr]I was talking about when the pounds are converted to Kilos before calculating displacement, since Kilos is the way to go, the math is always done wrong. What you are trying to point out...:-P That you know why we use Kilo's in the Balast programs?[/quote]Just that I would never use pounds in the formula. Also, when speaking of Tons, you have the metric ton which is 1000 kilograms and that is about 2205 pounds. Most people assume ton as a "short ton" which is 2000 pounds. As you can see, there's a couple hundred pounds difference between the two so it might not be a conversion issue but an assumed unit problem.[/quote]I've heard of short tons before, but never seen a case where they have been used (maybe that's because I don't live where people do USA measures). A metric ton (tonne) is 1000kg, and a long ton is 2240lb, so the difference between the two commonly used tons is only about 1.5%, not the 10% difference between the short ton and the tonne or the 12% difference between the short ton and the long ton. This means that the error mentioned (something over 1000 tons in 100000, so a bit over 1%) is far too big to have been cause by confusing short tons and metric tonnes and although it's about the right size for confusing metric tonnes and long tons that seems very unlikely to me because Sandroid wrote explicitly about conversion from pounds to kilograms, so it really is rounding error not terminological confusion.Sat, 26 Mar 2011 09:19:33 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]SanDroid (3/22/2011)[/b][hr]I was talking about when the pounds are converted to Kilos before calculating displacement, since Kilos is the way to go, the math is always done wrong. What you are trying to point out...:-P That you know why we use Kilo's in the Balast programs?[/quote]Just that I would never use pounds in the formula. Also, when speaking of Tons, you have the metric ton which is 1000 kilograms and that is about 2205 pounds. Most people assume ton as a "short ton" which is 2000 pounds. As you can see, there's a couple hundred pounds difference between the two so it might not be a conversion issue but an assumed unit problem.Tue, 22 Mar 2011 11:43:24 GMTcengland0http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]cengland0 (3/22/2011)[/b][hr][quote][b]SanDroid (3/22/2011)[/b][hr]Besides, isn't counting ballast by kilo's easier? One kilo of weight and one liter of water displacement equals neutral buoyancy. Doing that in another factor is 2.2 pounds for each 0.26417205263729593 (approx) US gallons of displacement.[/quote]I was talking about when the pounds are converted to Kilos before calculating displacement, since Kilos is the way to go, the math is always done wrong. What you are trying to point out...:-P That you know why we use Kilo's in the Balast programs?Tue, 22 Mar 2011 09:15:58 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]SanDroid (3/22/2011)[/b][hr]Great question. You would not believe how long and how often programers get this wrong. There is even a list that is maintained of ROM chips that do weight conversions incorrectly becuase Dec(6,2) is used instead of Dec(13,5)I even had to "show the math" on this exact thing a year ago when I had to explain why the weight conversion code used to change Pound to Kilos and vice versa was wrong in every appliation where I work. Not understanding this math is why so many ships have a problem balancing thier loads.Sometimes the cargo is weighed in pounds and the balast program uses Kilos.Then someone uses a cheap hand calculator to convert the 100,000 tons in pounds to Kilos and the weghts off by at least 1,000 tons.[/quote]Are you sure that extra weight isn't from the stowaways (Illegal aliens) that are aboard and unaccounted for?Besides, isn't counting ballast by kilo's easier? One kilo of weight and one liter of water displacement equals neutral buoyancy. Doing that in another factor is 2.2 pounds for each 0.26417205263729593 (approx) US gallons of displacement.Tue, 22 Mar 2011 08:47:23 GMTcengland0http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGreat question. You would not believe how long and how often programers get this wrong. There is even a list that is maintained of ROM chips that do weight conversions incorrectly becuase Dec(6,2) is used instead of Dec(13,5)I even had to "show the math" on this exact thing a year ago when I had to explain why the weight conversion code used to change Pound to Kilos and vice versa was wrong in every appliation where I work. Not understanding this math is why so many ships have a problem balancing thier loads.Sometimes the cargo is weighed in pounds and the balast program uses Kilos.Then someone uses a cheap hand calculator to convert the 100,000 tons in pounds to Kilos and the weghts off by at least 1,000 tons.Tue, 22 Mar 2011 08:38:21 GMTSanDroidhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxgreat qeustionTue, 22 Mar 2011 08:25:14 GMTSQLRNNRhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxExcellent question and nice explanation..Learned something new that Precision and Scale varies for the resulting value based on (+, -, / , *, [UNION | EXCEPT | INTERSECT] , % ) .Thanks for posting this...Tue, 22 Mar 2011 08:05:01 GMTGopi Shttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]Toreador (3/22/2011)[/b][hr][quote][b]Duncan Pryde (3/22/2011)[/b]That's kind of the "moral" of the question. Never use a "bigger" decimal/numeric than you actually need.[/quote]The moral I've drawn is that maybe Floats aren't as bad as we thought...[/quote]Until you want to do something like [url=http://www.sqlservercentral.com/questions/T-SQL/64521/]this[/url]:hehe:Tue, 22 Mar 2011 07:51:44 GMTDuncan Prydehttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]rlswisher (3/22/2011)[/b][hr]Declare @value1 numeric(38,10)Declare @value2 numeric(1,1)SET @value1 = 1234567890.123456789SET @value2 = 0.1SELECT @value1 SELECT @value2SELECT @value1 * @value2= "123456789.012345679"[/quote]As expected.Result precision is 38+1+1 = 40, scale is 10+1 = 11. Max allowed precision is 38, so precision and scale are reduced by 2, giving a final result precision and scale of 38,9 - which is why the result is rounded as you can see.Tue, 22 Mar 2011 06:56:26 GMTDuncan Prydehttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxDeclare @value1 numeric(38,10)Declare @value2 numeric(1,1)SET @value1 = 1234567890.123456789SET @value2 = 0.1SELECT @value1 SELECT @value2SELECT @value1 * @value2= "123456789.012345679"Tue, 22 Mar 2011 06:30:39 GMTrlswisherhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]Duncan Pryde (3/22/2011)[/b]That's kind of the "moral" of the question. Never use a "bigger" decimal/numeric than you actually need.[/quote]The moral I've drawn is that maybe Floats aren't as bad as we thought...Tue, 22 Mar 2011 04:25:19 GMTToreadorhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]Duncan Pryde (3/21/2011)[/b][hr][quote][b]michael.kaufmann (3/21/2011)[/b][hr][quote][b]tilew-948340 (3/20/2011)[/b][hr][...][/quote][...][/quote]Excellent explanation. Couldn't have put it better myself.[/quote]Thank you very much for your kind words of appreciation, Duncan.Thanks again for your question and great explanation.Regards,MichaelTue, 22 Mar 2011 04:04:09 GMTmichael.kaufmannhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]pksutha (3/22/2011)[/b][hr]My answer is like this [b]first part which is i 've answered:[/b]Declare @value1 decimal(20,10),@value2 decimal(20,3) SET @value1 = 1234567890.123456789SET @value2 = 0.1SELECT @value1 * @value2[b]Second part is screened answer:[/b]DECLARE @value1 DECIMAL(20,10), @value2 DECIMAL(30,13) SET @value1 = 1234567890.123456789SET @value2 = 0.1SELECT @value1 * @value2Ans:The screened answer is u 've declared value2 decimal(30,13)... why u need like that?my answer is Declare @value1 decimal(20,10),@value2 decimal(20,3)...... this is enough in SQL server 2005[/quote]That's kind of the "moral" of the question. Never use a "bigger" decimal/numeric than you actually need.Tue, 22 Mar 2011 03:11:29 GMTDuncan Prydehttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxMy answer is like this [b]first part which is i 've answered:[/b]Declare @value1 decimal(20,10),@value2 decimal(20,3) SET @value1 = 1234567890.123456789SET @value2 = 0.1SELECT @value1 * @value2[b]Second part is screened answer:[/b]DECLARE @value1 DECIMAL(20,10), @value2 DECIMAL(30,13) SET @value1 = 1234567890.123456789SET @value2 = 0.1SELECT @value1 * @value2Ans:The screened answer is u 've declared value2 decimal(30,13)... why u need like that?my answer is Declare @value1 decimal(20,10),@value2 decimal(20,3)...... this is enough in SQL server 2005Tue, 22 Mar 2011 01:37:46 GMTpksuthahttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]UMG Developer (3/21/2011)[/b][hr]Did you notice that the division increased the scale leaving you with three trailing zeros?If you look at the link in the explanation you will see that division uses a different formula:precision: p1 - s1 + s2 + max(6, s1 + p2 + 1)scale: max(6, s1 + p2 + 1) Notice that it favors the scale side since division usually results in more fractional digits, where multiplication favors the precision side.[/quote]oyeiuch! I was so focus to understand it that I forgot to follow the link.I understand now how to calculate itI know where to look for the formulaThank you all for your help:-)P.S. Now that I know how it is so complicated, I will probably never do a calculation again in SQL :hehe:Mon, 21 Mar 2011 17:59:10 GMTtilew-948340http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxDid you notice that the division increased the scale leaving you with three trailing zeros?If you look at the link in the explanation you will see that division uses a different formula:precision: p1 - s1 + s2 + max(6, s1 + p2 + 1)scale: max(6, s1 + p2 + 1) Notice that it favors the scale side since division usually results in more fractional digits, where multiplication favors the precision side.Mon, 21 Mar 2011 16:46:42 GMTUMG Developerhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]michael.kaufmann (3/21/2011)[/b][hr][quote][b]tilew-948340 (3/20/2011)[/b][hr]Why??? :crazy:[/quote]If you use a precsion of 23, the math is as follows:- Precision: 47 - 38 = 9- Scale: 20 - 9 = 11- Result: DECIMAL(38,11)[/quote]Ok! Now, I understand why a multiple calculation could truncate the answer Thank you very very much!But I still have a question: If you divide by 10 instead of multiply by 0.1, there is no truncation, but it is the same arithmetic calculation. Is the formula only apply to a multiplication?DECLARE @OneTenth DECIMAL(25,10) SET @OneTenth = 0.1DECLARE @FactorTen DECIMAL(25,10)SET @FactorTen = 10 DECLARE @value1C DECIMAL(25,10)SET @value1C = 1234567890.123456789SELECT @value1C*@OneTenth as CMult --(would give truncate answer 123456789.0123457)SELECT @value1C/@FactorTen as Cdiv --(would give all numbers and more 123456789.0123456789000)Mon, 21 Mar 2011 16:37:34 GMTtilew-948340http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]michael.kaufmann (3/21/2011)[/b][hr][quote][b]tilew-948340 (3/20/2011)[/b][hr]I am sorry, but I realy, realy don't understand why D is not good, even if I do your formula. Why is so that D would have a truncate answer and not C? I mean, both have a precision of 51 and only the scale is different (3 more digit more for C), which might explain something if you could explain my question here:If I declare D as precision of 23 instead of 25 and still having a scale of 10DECLARE @value1D DECIMAL(23,10), @value2D DECIMAL(23,10)it is still a precision over 38, and the scale is still 20 as previous, but the answer is not truncateWhy??? :crazy:[/quote]First of all a great big thank you to Duncan for this excellent QotD and the explanation.Whether the decimal result is 'truncated' or not is a mere mathematical question:D would result in precision 51 and scale 20; in order to not truncate the integer part of the numeral, SQL Server does the following:- maximum precision = 38, desired precision is 51 ==> 51 - 38 = 13- since it doesn't truncate the integer part, the decimal portion (scale) is truncated: 20 - 13 = 7.Hence the result for option D is DECIMAL(38,7).If you use a precsion of 23, the math is as follows:- Precision: 47 - 38 = 9- Scale: 20 - 9 = 11- Result: DECIMAL(38,11)However, as Duncan stated in his explanation, scale will never be less than 6; so the 'minimum' result in regards to scale will always be DECIMAL (38,6).Regards,Michael[/quote]Excellent explanation. Couldn't have put it better myself.Mon, 21 Mar 2011 14:15:06 GMTDuncan Prydehttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]Hugo Kornelis (3/21/2011)[/b][hr]Good question; superb explanation!I guess that if the author had included "all of the above" as a fifth answer option, the rate of incorrect answers would have been a lot higher. I guess that is the answer most respondents will first have in mind.[/quote]Funnily enough, the inspiration for this question came from you! I was doing some investigation into the float datatype following a previous QOTD, and came across [url=http://sqlblogcasts.com/blogs/alex_kuznetsov/archive/2007/10/26/when-sum-of-six-floats-depends-on-order-of-adding.aspx]this blog post[/url] from Alex Kuznetsov - with a comment by you that highlighted the rounding issues associated with numerics which I was not previously aware of. I then did a bit of reading and some experimenting and came up with the question.So thanks!Regarding the idea of an "all of the above" option - I did consider that, but decided that by not having one it would force people who were unaware of the rounding issue (like me up to a few weeks ago) to do some digging - either in BOL or by experimenting in SSMS.I'm really chuffed people liked the question anyway, and thanks to everyone for the kind comments.DuncanMon, 21 Mar 2011 13:13:36 GMTDuncan Prydehttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxIt's unanimous...great question, Duncan! Keep 'em coming.Mon, 21 Mar 2011 12:29:32 GMTRose Budhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGood question. Thank you.Mon, 21 Mar 2011 11:38:19 GMTmohammed moinudheenhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGood question. I learned something new. I always knew that decimal and numeric arithmetic did some sort of crazy type forcing that increased rounding errors; but I had never learned exactly how it worked. I [i]guessed[/i] (guessing is of course a stupid approach) that it probably damaged both the capability to store digits left of the decimal point and the capability to store digits right of the decimal point, which I now know to be hopelessly wrong - it just goes and maximises the rounding error (which I should have guessed - it's logical). The new knowledge has reinforced both my intention never to use decimal or numeric datatypes in SQL if their use can sensibly be avoided and my desire for a 128 bit version of float to augment the currectly supported 32 and 64 bit versions).Edit: given the way decimal and numeric types are defined, I can see where the decision to maximise the rounding error came from; that of course just reinforces my opinion that these are stupid definitions, that the inclusion of scale in the type definition is a relic from the dark ages of computing.Mon, 21 Mar 2011 09:34:07 GMTL' Eomot Inverséhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]tilew-948340 (3/20/2011)[/b][hr]I am sorry, but I realy, realy don't understand why D is not good, even if I do your formula. Why is so that D would have a truncate answer and not C? I mean, both have a precision of 51 and only the scale is different (3 more digit more for C), which might explain something if you could explain my question here:If I declare D as precision of 23 instead of 25 and still having a scale of 10DECLARE @value1D DECIMAL(23,10), @value2D DECIMAL(23,10)it is still a precision over 38, and the scale is still 20 as previous, but the answer is not truncateWhy??? :crazy:[/quote]Let's see if we can plug it in to the formula:D: DECIMAL (51,20) (25+25+1, 10+10)but we cannot go over precision 38, so the resulting isMax precision P: 38. So it needs to be reduced by 51-38 = 13.Since Scale can be defined as 0 <= S <= Pand we reduced the Precision by 130 <= (S-13) <= (P-13)we get S= 20-13 = 7.Now, let's do the same to your numbers:DECLARE @value1D DECIMAL(23,10), @value2D DECIMAL(23,10)The resulting would be:DECIMAL (46,20)Max Precision is 38. So it needs to be reduced by 8New ScaleS=20-8 = 12So, with your definition, you have even more wiggly roomEdit: I guess this concern already got answered.Mon, 21 Mar 2011 09:16:43 GMTMiguelSQLhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGood question.Even tough i got wrong i learned one point today.Thanks for QOTDMon, 21 Mar 2011 08:41:43 GMTmalleswarareddy_mhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGreat question.I must say, .NET Framework has one up on SQL here. Considering the following VB.NET code.[code="other"]System.Console.WriteLine(1234567890.123456789D * 0.1D * 0.1D)[/code]returns 12345678.90123456789 as expected which is simple.DECLARE @value1 DECIMAL(20,10), @value2 DECIMAL(2,1) , @value3 DECIMAL(2,1)Will return 12345678.901234567890 as expectedBut if you make a mistake and just use the same data type for all... DECIMAL(20,10) then it breaks.12345678.901235I guess we now know why we don't have a Product aggregate function in SQL.Mon, 21 Mar 2011 08:30:00 GMTBradley Deemhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxfantastic question!!!Mon, 21 Mar 2011 08:12:24 GMTrfr.ferrarihttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxExcellent question!!Mon, 21 Mar 2011 08:05:35 GMTSuriihttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]Hugo Kornelis (3/21/2011)[/b][hr]Good question; superb explanation!I guess that if the author had included "all of the above" as a fifth answer option, the rate of incorrect answers would have been a lot higher. I guess that is the answer most respondents will first have in mind.[/quote]That would have been the option I selected. Or, if the question was one of those "Select All That Apply" and were check boxes instead of radio buttons I would have selected them all.Mon, 21 Mar 2011 07:15:52 GMTcengland0http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxExcellent explanation, thanks.Mon, 21 Mar 2011 07:11:13 GMTDaniel Bowlinhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGood question; superb explanation!I guess that if the author had included "all of the above" as a fifth answer option, the rate of incorrect answers would have been a lot higher. I guess that is the answer most respondents will first have in mind.Mon, 21 Mar 2011 06:36:21 GMTHugo Kornelishttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGreat Question with even more great explanation. Good start for MondayMon, 21 Mar 2011 06:32:38 GMTsharath.chalamgarihttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxExcellent question but this one got me. At first, I thought they would all return the same results and I was wrong so I definitely learned something new today.Kudos to the author of this question.Mon, 21 Mar 2011 06:04:53 GMTcengland0http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGood question, great answer :-)Thanks,TomMon, 21 Mar 2011 04:52:26 GMThodgyhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspx[quote][b]tilew-948340 (3/20/2011)[/b][hr]I am sorry, but I realy, realy don't understand why D is not good, even if I do your formula. Why is so that D would have a truncate answer and not C? I mean, both have a precision of 51 and only the scale is different (3 more digit more for C), which might explain something if you could explain my question here:If I declare D as precision of 23 instead of 25 and still having a scale of 10DECLARE @value1D DECIMAL(23,10), @value2D DECIMAL(23,10)it is still a precision over 38, and the scale is still 20 as previous, but the answer is not truncateWhy??? :crazy:[/quote]First of all a great big thank you to Duncan for this excellent QotD and the explanation.Whether the decimal result is 'truncated' or not is a mere mathematical question:D would result in precision 51 and scale 20; in order to not truncate the integer part of the numeral, SQL Server does the following:- maximum precision = 38, desired precision is 51 ==> 51 - 38 = 13- since it doesn't truncate the integer part, the decimal portion (scale) is truncated: 20 - 13 = 7.Hence the result for option D is DECIMAL(38,7).If you use a precsion of 23, the math is as follows:- Precision: 47 - 38 = 9- Scale: 20 - 9 = 11- Result: DECIMAL(38,11)However, as Duncan stated in his explanation, scale will never be less than 6; so the 'minimum' result in regards to scale will always be DECIMAL (38,6).Regards,MichaelMon, 21 Mar 2011 03:53:52 GMTmichael.kaufmannhttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxGood question - an area often overlooked by developers.Mon, 21 Mar 2011 02:58:16 GMTpaul s-306273http://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxUnbelievable, but true!Thank you for qotd and a clear explanation!Mon, 21 Mar 2011 02:01:05 GMTCarlo Romagnanohttp://www.sqlservercentral.com/Forums/Topic1080873-2901-1.aspxVery good question, indeed. +++Mon, 21 Mar 2011 01:53:28 GMTChristian Buettner-167247