There's a big difference between some worker's desktop crashing and the database server your company depends on having errors. I agree marketshare is not proof of quality, but when Oracle and others have such a grip on the database server market, someone moving in as substantially as MS has in the last few years indicates a matching (if not better) mousetrap.
Thanks for the response. That makes a lot more sense. I still have trouble really believing there isn't a lot more to it (obviously there is - as you said, you're summarizing) because there's nothing non-standard about the code you stated above other than the sysobjects part.
Those are some good examples of a bad use of stored procedures you listed. I guess I'm just spoiled because I haven't had to deal with much like that. Yuck!
But aren't these the same people who complained there was a "security hole" in SQL Server if you didn't change the admin/sa password from its default of blank? They don't seem like they're very knowledgeable about the database they're using if that's the case.
There are millions upon millions of transactions running on SQL Servers every day. MS really wants to take the enterprise database market away from Oracle and they can't do that with this kind of bug. That isn't to say one couldn't exist (especially in 6.5), but this is just way too random not to have been noticed and patched before. When they start refusing patches as it states in the article (why!?!) I start thinking they're covering for their own embarrasement. Why didn't any of the other installations have this problem and only the one site was affected?
That's an interesting thought, but I think a threading bug would have turned up a lot more frequently than just the Russians and it would have received enough attention for a patch. But you might have something here.
What I can't figure out is why they refused the patch? Why would you do that? Someone else in this series of discussion suggested that they would have to modify a bunch of their source code and they didn't want to. If that's the case I don't know how this could be seen as a SQL Server bug since thousands of other custom clients attach to SQL just fine and don't have these problems. I don't know where they got that information, though, so it may not be true.
SQL routinely caches execution plans for commonly run queries to improve performance, but it doesn't cache the results of the queries, just how to most efficiently run them based on the last analysis of the table statistics referenced in the query. Even so, you can specify a stored procedure NOT cache at all which forces it to recompile every time you execute it. I have yet to see where Microsoft has said that breaking up the query is the way to go. That's what this guy you reference said he did to fix the problem on his own.
I agree that Oracle would have been a better choice. At least back in the 6.5 days, with 2000 I think that gap has been mostly closed.
Basing code on the sysobjects table is a bad idea in general though it has its uses. Personally, on a database as important as this I would never even think of basing my code on system objects. Also, this code really doesn't make any sense in the context of what the problem reportedly is, since sysobjects of type 'P' are stored procedures and not records of data. Why you would code anything like this other than for some kind of database modelling tool is unclear to me. What are they doing? Making a list of all stored procedures and then running them to put together their data set? That would seem pretty silly.
Your conclusion about stored procedures is entirely misguided. On SQL Server, stored procedures provide performance improvements since the server can create execution plans based on table statistics to maximize performance in most cases. Running adhoc SQL against the database does not allow for this performance boon. The only way using a stored procedure show lack of understanding is if you use it without being able to write it. Even that is a potential benefit since you can then build on the work of programmers more experienced and knowledgeable than yourself.
From what you've said here, though, it still sounds like a bug in the accounting software, not the SQL Server. If you have to modify source code to fix it then how is the problem not in your own code?
I'm missing where you're getting this information. As a serious user of SQL Server I am highly interested in anything that might actually affect me. If you've got another source, could you site it so I can read up please?
I'm not being hostile. Your post insinuates the insult. I simply provided a possible answer to your question.
I'm seriously interested in the bug number and I didn't see it (and still don't). Am I just overlooking it?
Your first post sounds a lot like unsupported bias and I'm afraid I'll keep taking it that way until I see the proof in the pudding.
And no, I don't own any MS stock and don't have any vested interest in their wellbeing other than I think they have driven the market to a much better place than it would be without them, regardless of whether their products are actually the best.
Cmon, a lot of bugs DO get fixed when people complain or otherwise MS would never have grown into the behemoth that it now is. Ever heard of a service pack?
But I agree that they don't always fix their bugs in the existing product, instead forcing you to upgrade (paying more money of course) to a newer version that now no longer contains the original bug. That is wrong. Upgrades should be to driven by new features (real features, not MS PR department's use of the word), not fixing bugs. I think this is usually the case, but sometimes MS lets go and stops supporting old products too quickly.
I went to Iowa State University in Ames and did have some dealings with both the nuclear engineering department and the U.S. DOE facility there through the physics department and have written a fair amount of FORTRAN myself, though several years ago now.
If the customized accounting package at the one facility that had the error was based on standards and peer-reviewed to be more like the packages at all the other facilities that DID work then maybe they would have avoided the problem in the way you describe above.
Enterprise customers don't tolerate computational errors either and the proof is in the marketplace, where SQL Server is gaining marketshare, not losing it.
It's also worth mentioning that the systems you describe above are designed for a specific purpose and can afford to stay mostly "legacy" because they don't support thousands of different businesses that use them for thousands of different purposes. Maybe the Russians should have used something time tested for their accounting software, but their database engine software works just fine.
And what is this bug number? Have you got information not stated in any of the articles listed above and just haven't given use the source? Is that because it isn't true and you're just posting because you don't like Microsoft?
If you've got something to back this up then I'm interested, otherwise I think the answer to your question is, "you are."
I did read the article and I stand by my opinion. A programmer must audit the results of their code as well as the code itself. If their very specific scenario could be recreated, it could be avoided.
The article says:
------
The bug surfaced only in the customized accounting software running on SQL Server and did not appear at other customer sites, said Steve Murchie, Microsoft's group product manager for SQL Server.
Microsoft offered to create a bug fix last year, but the Russian scientists didn't want it, said Murchie.
------
That doesn't indicate an error in SQL Server, just in how this customized accounting software uses it.
I can't see why open software would be any better than closed software in this case. Hey! I found a bug in my nuclear materials storage database, let's ask 10,000 unknown persons if they can take a look at it and fix it. Meanwhile, they've all moved on to the next "l33t" thing and abandoned what I'm running. I believe that in many cases it's more important to hitch your wagon to someone who you know will be around and have a vested interest in keeping you and others like you happy.
I think the first part of your post supports my position rather than opposes it.
As for lack of continued support of a product without having to continually upgrade to newer versions at additional cost, I agree with you. That sucks.
That's why I stated in my comment above that a competent programmer audits not only his/her code, but also the results of that code. Perfectly logical code may still not return what you intend because you forgot to account for some special case. I don't see anywhere in the articles on this that the same query run against the same data will return different results on subsequent runs. If certain data sets cause the query to behave not as expected, then the query needs to be modified to account for whatever the special case in the data is.
I've written way too many queries with way too many special cases to believe that one of them would just start skipping records without it being caused by something in the data I forgot to account for.
Your example is too simple. I believe this error is more likely to be something like your sin function above being used in a calculation that works 999 times out of 1000, but that 1000th time you multiply it times something that causes it to lose significant figures because the data type you're using doesn't have enough placeholders and you get a bad result. That said, if it really was actually returning a bad result I certainly wouldn't blame you for properly cursing out the culprit. It's just much more probably the result of an error in the user's code than in a product that gets used SO much. But anything is possible, however unlikely.
I won't positively rule out that there was some fault on MS's part. I'm just saying that in the dozens of SQL Server applications I've worked on and for the hundreds of clients I've worked with who have SQL Server projects, NONE of us have ever run across a bug that loses records. And I've programmed some really weird stuff on occasion. What could really be that complex in an inventory management system, even if it is for nuclear materials that thousands of others wouldn't have run across as well? And if you read the updates in the service packs for SQL Server, you'll see that MS patches some pretty arcane stuff.
And I've written code that didn't work correctly. Then I fixed it when I audited my results. Almost all complicated software has quirks in it. Should it be fixed? Yes. Do people handling nuclear material records have a responsibility to audit their code regardless of whether bugs might exist? Also yes. A good programmer checks the results of their code as well as the code itself.
My scenario was pretty complicated too. The point is that the server responded the same way every time according to the way it was programmed. Now I'm not saying that there weren't any bugs in 6.5 or 7.0 for that matter, but you would think that the programmers would have checked their code for something this important. Judging by the "security hole" of not changing the default admin/sa password, I would say the chances are pretty heavily in favor of bad programming. To give them ~some~ credit, it is pretty easy to code in a "bug" when you're dealing with complex SQL and a lot of data that may have special cases. Still, it's NUCLEAR material!
I ran a SQL Server 6.5 database that handled 7GB of data a month and processed around 21 billion transactions on that data, then countless more on the "rolled up" summaries. We had a general ledger to reconcile with and I think we would have noticed missing records if they occured every 1000 transactions. SQL 6.5 was a pain in the ass and 7.0 is a lot better. It still has some problems, but I think these reported "bugs" are more bad programmers than bad server software.
There just isn't any conclusive proof of humans having an effect on global warming. I used to attend Iowa State University as a physics major. When Freeman Dyson, whom some of you may have heard of, visited as a guest lecturer, us geek physics students got to have a Q&A session of our own with him. One of the big topics was global warming and his view was that there was a lack of accurate data so vast that nothing conclusive would be possible for a couple of centuries.
If you look at studies that have been done, most of them don't report any findings that conclude humans have had any effect, but environmental groups only tote the few that do.
Global warming may be partially caused by us and then again we may contribute 1% to what is just a cycle that we are a small cog in. I think it merits further study, but not immediate action and should definitely NOT be used as a boogeyman to scare our kids into hating large corporations.
The average user isn't interested in the benefits of good wireless coverage and what it can get them. There just isn't a big enough market for a company like this to make money at this time. My parents were appalled that I paid $50/month for DSL when they got "perfectly good Internet on [their] 56K AOL account". Maybe someday if we're lucky wireless service will be economical enough and useful enough to attract an audience that can support the size of company required to provide good service. I've got my fingers crossed.
As I stated, this is my opinion based on things I heard firsthand from execs of theirs and from personal inferences from their strategies and press releases. I can't prove it, but then again they couldn't have proved Microsoft had a vendetta against Netscape if they hadn't subpoena'd their internal e-mail. It's just what I think.
As for Visual Studio, I grew up on gcc, but I found I liked VisStud a lot better after I got acquainted with the MFC. Not that there isn't a lot of room for improvement, but that's true of every development tool.
The release of Visual Studio.NET that I've played with was very impressive, allowing developers to switch seemlessly from one language to another while still providing consistent error handling and transactions across the whole process. That will be key for really coding in components and since you can make calls to components located on other servers all in the same transaction with.NET it should really make for some cool stuff. And they appear to have done away with DLL Hell. Lastly, no one seems to give them any credit, but anyone can develop their own.NET versions of languages as long as they provide a mid-level compiler. I think there's even a Pascal.NET on the way. Microsoft is learning from its mistakes too!
Ummm, I like Visual Studio a lot. I didn't have much of a problem with Sun until a keynote address I attended from one of their execs. It was like listening to Larry Ellison. Sun open sources its software to make Microsoft look bad. Plain and simple. Whether that's a bad things or not is a matter of opinion, but I think their motivation is out of hatred in their execs for Microsoft and not out of any support for the open source movement.
Slashdot Mirror
There's a big difference between some worker's desktop crashing and the database server your company depends on having errors. I agree marketshare is not proof of quality, but when Oracle and others have such a grip on the database server market, someone moving in as substantially as MS has in the last few years indicates a matching (if not better) mousetrap.
Thanks for the response. That makes a lot more sense. I still have trouble really believing there isn't a lot more to it (obviously there is - as you said, you're summarizing) because there's nothing non-standard about the code you stated above other than the sysobjects part.
Those are some good examples of a bad use of stored procedures you listed. I guess I'm just spoiled because I haven't had to deal with much like that. Yuck!
But aren't these the same people who complained there was a "security hole" in SQL Server if you didn't change the admin/sa password from its default of blank? They don't seem like they're very knowledgeable about the database they're using if that's the case.
There are millions upon millions of transactions running on SQL Servers every day. MS really wants to take the enterprise database market away from Oracle and they can't do that with this kind of bug. That isn't to say one couldn't exist (especially in 6.5), but this is just way too random not to have been noticed and patched before. When they start refusing patches as it states in the article (why!?!) I start thinking they're covering for their own embarrasement. Why didn't any of the other installations have this problem and only the one site was affected?
That's an interesting thought, but I think a threading bug would have turned up a lot more frequently than just the Russians and it would have received enough attention for a patch. But you might have something here.
What I can't figure out is why they refused the patch? Why would you do that? Someone else in this series of discussion suggested that they would have to modify a bunch of their source code and they didn't want to. If that's the case I don't know how this could be seen as a SQL Server bug since thousands of other custom clients attach to SQL just fine and don't have these problems. I don't know where they got that information, though, so it may not be true.
SQL routinely caches execution plans for commonly run queries to improve performance, but it doesn't cache the results of the queries, just how to most efficiently run them based on the last analysis of the table statistics referenced in the query. Even so, you can specify a stored procedure NOT cache at all which forces it to recompile every time you execute it. I have yet to see where Microsoft has said that breaking up the query is the way to go. That's what this guy you reference said he did to fix the problem on his own.
I agree that Oracle would have been a better choice. At least back in the 6.5 days, with 2000 I think that gap has been mostly closed.
Basing code on the sysobjects table is a bad idea in general though it has its uses. Personally, on a database as important as this I would never even think of basing my code on system objects. Also, this code really doesn't make any sense in the context of what the problem reportedly is, since sysobjects of type 'P' are stored procedures and not records of data. Why you would code anything like this other than for some kind of database modelling tool is unclear to me. What are they doing? Making a list of all stored procedures and then running them to put together their data set? That would seem pretty silly.
Your conclusion about stored procedures is entirely misguided. On SQL Server, stored procedures provide performance improvements since the server can create execution plans based on table statistics to maximize performance in most cases. Running adhoc SQL against the database does not allow for this performance boon. The only way using a stored procedure show lack of understanding is if you use it without being able to write it. Even that is a potential benefit since you can then build on the work of programmers more experienced and knowledgeable than yourself.
From what you've said here, though, it still sounds like a bug in the accounting software, not the SQL Server. If you have to modify source code to fix it then how is the problem not in your own code?
I'm missing where you're getting this information. As a serious user of SQL Server I am highly interested in anything that might actually affect me. If you've got another source, could you site it so I can read up please?
I'm not being hostile. Your post insinuates the insult. I simply provided a possible answer to your question. I'm seriously interested in the bug number and I didn't see it (and still don't). Am I just overlooking it? Your first post sounds a lot like unsupported bias and I'm afraid I'll keep taking it that way until I see the proof in the pudding. And no, I don't own any MS stock and don't have any vested interest in their wellbeing other than I think they have driven the market to a much better place than it would be without them, regardless of whether their products are actually the best.
Cmon, a lot of bugs DO get fixed when people complain or otherwise MS would never have grown into the behemoth that it now is. Ever heard of a service pack?
But I agree that they don't always fix their bugs in the existing product, instead forcing you to upgrade (paying more money of course) to a newer version that now no longer contains the original bug. That is wrong. Upgrades should be to driven by new features (real features, not MS PR department's use of the word), not fixing bugs. I think this is usually the case, but sometimes MS lets go and stops supporting old products too quickly.
I went to Iowa State University in Ames and did have some dealings with both the nuclear engineering department and the U.S. DOE facility there through the physics department and have written a fair amount of FORTRAN myself, though several years ago now.
If the customized accounting package at the one facility that had the error was based on standards and peer-reviewed to be more like the packages at all the other facilities that DID work then maybe they would have avoided the problem in the way you describe above.
Enterprise customers don't tolerate computational errors either and the proof is in the marketplace, where SQL Server is gaining marketshare, not losing it.
It's also worth mentioning that the systems you describe above are designed for a specific purpose and can afford to stay mostly "legacy" because they don't support thousands of different businesses that use them for thousands of different purposes. Maybe the Russians should have used something time tested for their accounting software, but their database engine software works just fine.
And what is this bug number? Have you got information not stated in any of the articles listed above and just haven't given use the source? Is that because it isn't true and you're just posting because you don't like Microsoft?
If you've got something to back this up then I'm interested, otherwise I think the answer to your question is, "you are."
I did read the article and I stand by my opinion. A programmer must audit the results of their code as well as the code itself. If their very specific scenario could be recreated, it could be avoided.
The article says:
------
The bug surfaced only in the customized accounting software running on SQL Server and did not appear at other customer sites, said Steve Murchie, Microsoft's group product manager for SQL Server.
Microsoft offered to create a bug fix last year, but the Russian scientists didn't want it, said Murchie.
------
That doesn't indicate an error in SQL Server, just in how this customized accounting software uses it.
I can't see why open software would be any better than closed software in this case. Hey! I found a bug in my nuclear materials storage database, let's ask 10,000 unknown persons if they can take a look at it and fix it. Meanwhile, they've all moved on to the next "l33t" thing and abandoned what I'm running. I believe that in many cases it's more important to hitch your wagon to someone who you know will be around and have a vested interest in keeping you and others like you happy.
I think the first part of your post supports my position rather than opposes it.
As for lack of continued support of a product without having to continually upgrade to newer versions at additional cost, I agree with you. That sucks.
That's why I stated in my comment above that a competent programmer audits not only his/her code, but also the results of that code. Perfectly logical code may still not return what you intend because you forgot to account for some special case. I don't see anywhere in the articles on this that the same query run against the same data will return different results on subsequent runs. If certain data sets cause the query to behave not as expected, then the query needs to be modified to account for whatever the special case in the data is.
I've written way too many queries with way too many special cases to believe that one of them would just start skipping records without it being caused by something in the data I forgot to account for.
Your example is too simple. I believe this error is more likely to be something like your sin function above being used in a calculation that works 999 times out of 1000, but that 1000th time you multiply it times something that causes it to lose significant figures because the data type you're using doesn't have enough placeholders and you get a bad result. That said, if it really was actually returning a bad result I certainly wouldn't blame you for properly cursing out the culprit. It's just much more probably the result of an error in the user's code than in a product that gets used SO much. But anything is possible, however unlikely.
I won't positively rule out that there was some fault on MS's part. I'm just saying that in the dozens of SQL Server applications I've worked on and for the hundreds of clients I've worked with who have SQL Server projects, NONE of us have ever run across a bug that loses records. And I've programmed some really weird stuff on occasion. What could really be that complex in an inventory management system, even if it is for nuclear materials that thousands of others wouldn't have run across as well? And if you read the updates in the service packs for SQL Server, you'll see that MS patches some pretty arcane stuff.
And I've written code that didn't work correctly. Then I fixed it when I audited my results. Almost all complicated software has quirks in it. Should it be fixed? Yes. Do people handling nuclear material records have a responsibility to audit their code regardless of whether bugs might exist? Also yes. A good programmer checks the results of their code as well as the code itself.
My scenario was pretty complicated too. The point is that the server responded the same way every time according to the way it was programmed. Now I'm not saying that there weren't any bugs in 6.5 or 7.0 for that matter, but you would think that the programmers would have checked their code for something this important. Judging by the "security hole" of not changing the default admin/sa password, I would say the chances are pretty heavily in favor of bad programming. To give them ~some~ credit, it is pretty easy to code in a "bug" when you're dealing with complex SQL and a lot of data that may have special cases. Still, it's NUCLEAR material!
I meant 21 MILLION, not billion. Sorry.
I ran a SQL Server 6.5 database that handled 7GB of data a month and processed around 21 billion transactions on that data, then countless more on the "rolled up" summaries. We had a general ledger to reconcile with and I think we would have noticed missing records if they occured every 1000 transactions. SQL 6.5 was a pain in the ass and 7.0 is a lot better. It still has some problems, but I think these reported "bugs" are more bad programmers than bad server software.
But they know the AC's IP address (unless they dump their logs) and can trace that back to their ISP who can then give out the owner's info.
There just isn't any conclusive proof of humans having an effect on global warming. I used to attend Iowa State University as a physics major. When Freeman Dyson, whom some of you may have heard of, visited as a guest lecturer, us geek physics students got to have a Q&A session of our own with him. One of the big topics was global warming and his view was that there was a lack of accurate data so vast that nothing conclusive would be possible for a couple of centuries.
If you look at studies that have been done, most of them don't report any findings that conclude humans have had any effect, but environmental groups only tote the few that do.
Global warming may be partially caused by us and then again we may contribute 1% to what is just a cycle that we are a small cog in. I think it merits further study, but not immediate action and should definitely NOT be used as a boogeyman to scare our kids into hating large corporations.
The average user isn't interested in the benefits of good wireless coverage and what it can get them. There just isn't a big enough market for a company like this to make money at this time. My parents were appalled that I paid $50/month for DSL when they got "perfectly good Internet on [their] 56K AOL account". Maybe someday if we're lucky wireless service will be economical enough and useful enough to attract an audience that can support the size of company required to provide good service. I've got my fingers crossed.
As I stated, this is my opinion based on things I heard firsthand from execs of theirs and from personal inferences from their strategies and press releases. I can't prove it, but then again they couldn't have proved Microsoft had a vendetta against Netscape if they hadn't subpoena'd their internal e-mail. It's just what I think. As for Visual Studio, I grew up on gcc, but I found I liked VisStud a lot better after I got acquainted with the MFC. Not that there isn't a lot of room for improvement, but that's true of every development tool. The release of Visual Studio .NET that I've played with was very impressive, allowing developers to switch seemlessly from one language to another while still providing consistent error handling and transactions across the whole process. That will be key for really coding in components and since you can make calls to components located on other servers all in the same transaction with .NET it should really make for some cool stuff. And they appear to have done away with DLL Hell. Lastly, no one seems to give them any credit, but anyone can develop their own .NET versions of languages as long as they provide a mid-level compiler. I think there's even a Pascal.NET on the way. Microsoft is learning from its mistakes too!
Ummm, I like Visual Studio a lot. I didn't have much of a problem with Sun until a keynote address I attended from one of their execs. It was like listening to Larry Ellison. Sun open sources its software to make Microsoft look bad. Plain and simple. Whether that's a bad things or not is a matter of opinion, but I think their motivation is out of hatred in their execs for Microsoft and not out of any support for the open source movement.