|
|
|
SSChampion
Group: Administrators
Last Login: Today @ 5:02 PM
Points: 23,164,
Visits: 6,924
|
|
|
|
|
|
SSCrazy
Group: General Forum Members
Last Login: Today @ 3:16 PM
Points: 2,406,
Visits: 1,869
|
|
So in other words, be nice, even if the answer is that was a really stupid thing to do? Over the years I've inherited many peoples great ideas and had to make them work and rarely could I ask (out loud) who is the idiot who built this thing? And I'm sure someone could ask that about some of my really early work..
I just wish that people would do a search of the forum or a google search before asking a question here.. And then they could ask a question that is more closely tied to their problem.. Also maybe get an idea of what information they need to post..
CEWII
--------------------------------
Having trouble figuring out what jobs are running in SQL Server at the same time.
Try Sql Job History Visualization
It lets you view your SQL Job history on an Outlook style calendar..
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Thursday, March 11, 2010 6:14 AM
Points: 115,
Visits: 456
|
|
| I recently installed sql server 2005 on one of my computers with win vista, I installed everything there was to install and patches etc and it of course worked great. Then a couple of years later, one month ago, I wanted to remove sql server 2005 from that computer and I did get to remove a few parts and then suddenly I could not remove sql server 2005. Some of the parts could not be found but some parts of sql server would anyway start up on restart. It just didnt work to remove them by the control panel. So that's my warning to you all, before you remove sql server, search a bit first on how that best is done, instead of like me, just starting to remove each thing listed in the control panel that I wanted removed since sql server was just not a single item in that list as you may know. It really was annoying.
|
|
|
|
|
Mr or Mrs. 500
Group: General Forum Members
Last Login: Wednesday, November 18, 2009 3:18 AM
Points: 527,
Visits: 82
|
|
Oops... that closing sentence hurts... glad I'm not the only person who ever did that 
|
|
|
|
|
SSC Veteran
Group: General Forum Members
Last Login: 2 days ago @ 8:30 AM
Points: 288,
Visits: 1,026
|
|
PostXript (9/1/2009)
Oops... that closing sentence hurts... glad I'm not the only person who ever did that
That's a major reason we don't allow scripts to be run against production unless the results have been tested by the end users in an acceptance system. Even simple Update table set flag = 1 require a change management documetn in our environment. To make it even more difficult to induce errors, the DBA's that execute the scripts have nothing to do with creating the scripts.
|
|
|
|
|
Mr or Mrs. 500
Group: General Forum Members
Last Login: Wednesday, November 18, 2009 3:18 AM
Points: 527,
Visits: 82
|
|
I totally agree, this was a few years back. In my current environment it's no longer possible for me to make these kind of mistakes.
Ross McMicken (9/1/2009)
PostXript (9/1/2009)
Oops... that closing sentence hurts... glad I'm not the only person who ever did that That's a major reason we don't allow scripts to be run against production unless the results have been tested by the end users in an acceptance system. Even simple Update table set flag = 1 require a change management documetn in our environment. To make it even more difficult to induce errors, the DBA's that execute the scripts have nothing to do with creating the scripts.
|
|
|
|
|
SSCrazy
Group: General Forum Members
Last Login: Today @ 3:54 PM
Points: 2,387,
Visits: 5,202
|
|
Note 2 in the following URL would suggest that you can upgrade from evaluation edition to enterprise (or any other)
http://msdn.microsoft.com/en-us/library/ms143393(SQL.90).aspx.
I suspect this becomes untrue once service packs have been applied? If someone attempts to upgrade and it does not work the real error would be with microsoft documentation in not making it crystal clear (in one place) what you can and cannot do.
|
|
|
|
|
SSC Veteran
Group: General Forum Members
Last Login: 2 days ago @ 8:30 AM
Points: 288,
Visits: 1,026
|
|
PostXript (9/1/2009)
I totally agree, this was a few years back. In my current environment it's no longer possible for me to make these kind of mistakes. Ross McMicken (9/1/2009)
PostXript (9/1/2009)
Oops... that closing sentence hurts... glad I'm not the only person who ever did that That's a major reason we don't allow scripts to be run against production unless the results have been tested by the end users in an acceptance system. Even simple Update table set flag = 1 require a change management documetn in our environment. To make it even more difficult to induce errors, the DBA's that execute the scripts have nothing to do with creating the scripts.
I forgot to mention that the folks who CAN make changes in production have to log in using a special ID that doesn't do any routine activites like email and has no authority in test or ddevelopment. That prevents the big oops that happens when you use an ID in the wrong environment. "Gee, I thought I was in test, not production"
|
|
|
|
|
Valued Member
Group: General Forum Members
Last Login: Thursday, September 03, 2009 3:46 PM
Points: 69,
Visits: 55
|
|
Back to the original statement of "... you shouldn't have installed all that for an evaluation edition" - why not? Isn't that why we have evaluation editions: to see if they work, or not, with various components? Yeah, I know that this isn't necessarily the direction this blog is going, but it makes sense to me to install evaluation editions of not only SQL Server but 3rd party vendor / in-house developer software and see how it plays out against the existing parts and pieces of the environment.
|
|
|
|
|
SSC-Enthusiastic
Group: General Forum Members
Last Login: Yesterday @ 1:27 PM
Points: 178,
Visits: 578
|
|
I agree that this kind of comment - "you shouldn't have done that" - is totally counter-productive, but I also think Microsoft does a regularly lousy job with releases, updates, and installs.
We have dealt a great deal with clients who installed SQL Express and then tried to move to full versions, and had bizarre problems. We've also had our share of support calls over clients changing SQL versions. When you go to the web to find documents to help you out, without exception, the worst instructions come from Microsoft themselves who seem hell-bent on always, always, always over-complicating such "help". One of our clients tried to follow an MS document that suggested tweaking the registry and that was a three day support call!
Case in point, Microsoft's recent release of Visual Studio 2008 hoses up Winzip. They released an SP1 update which not only DID NOT fix this problem, it added a new problem causing Windows Media Player to lock up. Microsoft has "acknowledged" the problem, but has said nothing about a fix, and worse, is behaving like this is somehow 'okay'. (Anyone experiencing these problems can go to the MSDN forums where some "phixes" are presented by end-users - they are not pretty, but work for the most part).
Yes, we all make mistakes, I agree - but when the company building the software makes a mistake there has to be something more than just an 'acknowledgement' of the problem and the attendant months-long wait for the real fix. It strikes me that if I took my car into the dealer and he screwed up my car worse than when I brought it in, it would not be acceptable for them to tell me my car would be fixed in some nebulous amount of months.
In short, I sure would love to tell Microsoft; "You shouldn't have done that!!!"
There's no such thing as dumb questions, only poorly thought-out answers...
|
|
|
|
