MS Sql Server contributes to nuclear instability

Post #2,082 by bbronson 7/17/01 3:01:49 PM Reply	MS Sql Server contributes to nuclear instability (apologies if this has already been posted; I sought but did not find, so...) MS Sql server loses records. This was found by Russian nuclear weapons scientists in the database software provided to them by Los Alamos. This software is used to track nuclear material. And it loses 1 record in every 1000. The Russians kept their paper and pencil records, so their records are not totally screwed. The US, on the other hand... Original article: href=[link\|http://www.cdi.org/nuclear/blair071101.html\|http://www.cdi.org/...r071101.html] (Reference material at the bottom of the article.) Summarized in this article: [link\|http://www.sfgate.com/cgi-bin/article.cgi?file=/chronicle/archive/2001/07/16/BU162103.DTL\|http://www.sfgate.c...BU162103.DTL] (About halfway down the article.) Would someone remind me why the world continues to use Mickeysoft? I can't for the life of me figure it out. Brian Bronson An employee with a brain whose employer is VOLUNTARILY going the Mickeysoft way BTW: First Post!! (in this new arena)
Post #2,098 by Ashton 7/17/01 4:16:43 PM Reply	Yup.. somewhere around here - I posted a comment on CDI -- who broke this story, picked up by one of the monopoly newspaper publishers. They be heap good bunch of sleuths, proof that not every org. in downtown DC - are a bunch of slime. Veni vidi - and they were sharp, esp. Adm. Carroll. As to M$ - PT Barnum was Right (were they ever!) M$ survival is IMO a direct laboratory measure of the Gullibility Factor extant. Today - despite all the infotainment, DOJ published material, and the Great Minds of the Western World assembled here: Bullshit always drives out the Pearls of Wisdom\ufffd when your audience is a pack of consuming-besotted sheep, with the attention span of a fruit fly. QED. Ashton
Post #2,153 by ChrisR 7/17/01 10:25:16 PM Reply	Not to justify the bug... ...but I personally dislike the construct which induces the bug. From the documentation we have the following which causes the problem: DECLARE @x int, @t varchar (255), @r int SELECT @x = 0 SELECT @x = id FROM sysobjects WHERE (id > @x) AND (type = 'P') ORDER BY id DESC SELECT @r = @@ROWCOUNT /* COMMENT: Printing our resulting value of @x and @r */ SELECT @t = 'Resulting value of @x = ' + CONVERT(VARCHAR, @x) PRINT @t SELECT @t = 'Number of records in data set @r = ' + CONVERT(VARCHAR, @r) PRINT @t GO I've marked in red what causes the difficulty. Specifically, what is happening seems to be that the variable is both used in the WHERE clause and is being assigned to. Technically, the software should take a flash of the @x value prior to running the query and use that pre-query value for the entire query. What is likely happening, though, is that the value of @x is really just a pointer. So the WHERE clause is using a value of the @x variable that is changing as the query is trundling through the rows. Anyhow, I dislike the construct because it is a bit confusing for the reason that it's not obvious you are (a) relying on the value of @x to be a constant in the WHERE clause while (b) assigning the value of the last row returned to the variable when completed. It is much better to (a) use seperate variables for the two distinct purposes; and (b) construct the query such that it only returns one row - the row that actually contains the required data. Anyhow, register me as one that thinks that it is a trick in T-SQL that should be avoided - whether it works as advertized or not.

Welcome to IWETHEY!