Worst Practices - Making a "Live" Change
-
Great comments and thanks. This is one of those areas that I preach, though still can't always control. Unless you have complete control of the server, no one else makes changes, you will have a tough time here.
I agree with most of what's been written (sorry for the delay in sounding off, but been on vacation, unwired
). No matter how critical a system is, waiting another 5 minutes, 2 hours, whatever to test is more important than not doing it. Making the changes on the 5 minute system can kill you on Friday if it wasn't tested. If you are talking about making the change on Monday and testing it before it runs live on Fri, I'd argue it isn't a live system until Fri and might agree that you need to make the change (if you don't have a test box). But you better be ready to roll back (http://www.sqlservercentral.com/columnists/sjones/vcspart4.asp) and get it running Fri morning before it's needed.Steve Jones
-
quote:
If you are talking about making the change on Monday and testing it before it runs live on Fri, I'd argue it isn't a live system until FriThat one comment has changed the whole way I'm looking at this - thanks Steve.
Ryan Randall
Solutions are easy. Understanding the problem, now, that's the hard part.
-
-
I am a developer and I make live adhoc changes all the time. the syntax checker on sql server catches typos, normally its to fix things that aren't working correctly in the first place. hard to make things worse
in my opinion and experience. the global.asax file emails any errors as they occur on the website, so as long as I make the changes first thing in the morning, I know I'm going to be around to fix things immediately if even 1 user/customer has a problem/error. -
You're remark about adding a column being a "minimal" change made me think of something that should itself be listed as a bad practice: not specifying a column list in INSERT statements (and it's cousin, using * in SELECT statements instead of a column list).
Ordinarily, adding a column would be a minimal change.....if all stored procedures/etc. in the DB were written with column list arguments. Otherwise an object that executes "INSERT Table1 VALUES ('value1', 'value2', 'value3')" will fail if Table1, which once had 3 columns, now has 4. Likewise, an object that executes "SELECT *" against such a table may end up returning more columns than needed.
-
Developers always think it's a minimal change and I can easily back it out. What if your syntax (SQL) is correct, but you miss a join and implment a cross product? You could easily hang the SQL Server. You could easily cause other issues that might be backed out, but cause damage.
Making a live change without control is a bad practice. Not that it always fails, but it's a worst practice.
Not specifying a column list is a good one as well.
). No matter how critical a system is, waiting another 5 minutes, 2 hours, whatever to test is more important than not doing it. Making the changes on the 5 minute system can kill you on Friday if it wasn't tested. If you are talking about making the change on Monday and testing it before it runs live on Fri, I'd argue it isn't a live system until Fri and might agree that you need to make the change (if you don't have a test box). But you better be ready to roll back (Viewing 6 posts - 16 through 20 (of 20 total)
You must be logged in to reply to this topic. Login to reply