October 25, 2016 at 8:09 am
Jeff Moden (10/23/2016)
The difference between Zombies and Clowns is simple. Zombies are external sources. Clowns are internal. đŸ˜‰
A disgruntled DBA is the equivalent of a zombie clown with a suitcase full of chaos monkeys.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 25, 2016 at 9:28 am
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."
So yes, we often did do it to ourselves.
October 25, 2016 at 10:46 am
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 25, 2016 at 11:41 pm
Gary Varga (10/25/2016)
Geoff.Sturdy (10/25/2016)
Gary - the two digit year was born out if the need to conserve memory in early systems - back in the late 70s /early 80s memory was expensive and every byte counted (anyone remember 77 levels in Cobol? ) so while we (the industry) "did it to ourselves" there was a goo reason for itA reason but arguable either way. We had this discussion at college (17-18 year olds) with a lecturer in the late 1980s. The greneral consensus was that the risk coupled with the inevitable cost of resolving would likely prove more unsavoury than the cost of a four digit year. That was before the inflated costs of "Y2K Consultants" was even imagined.
The real embarrassment are those tales of people creating programs utilising two digit years alongside those working on a Y2K project.
Don't forget the 3 digit year byte huggers. đŸ˜› You know the ones. 050 was 1950 and 150 is 2050. All fun stuff. The fun still isn't over. A lot of people still think it's a good idea to store data the way they'll put it on a report. :sick: What's really fun are the ones that think storing such things as dates in an NVARCHAR(MAX) is them being clever and avoiding Knuth's parable on pre-optimization being the root of all evil. Yeah... ton's o' fun.
--Jeff Moden
Change is inevitable... Change for the better is not.
October 25, 2016 at 11:45 pm
Eric M Russell (10/25/2016)
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
I hope you live until then and... I hope the last voice you hear is mine. đŸ˜€
--Jeff Moden
Change is inevitable... Change for the better is not.
October 26, 2016 at 4:50 am
Eric M Russell (10/25/2016)
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
We've just identified a system in place here that has a we-can't-be-bothered-to-figure-out-how-to-use-NULL-properly-and-we're-never-going-to-see-this-date bug that's less than a decade away. This system is using an unknown date substitute of 2025-12-31.
Now, nine years *should* be long enough to migrate away from this particular POS, but Murphy and Parkinson (particularly Parkinson) are strong in this place...
Thomas Rushton
blog: https://thelonedba.wordpress.com
October 26, 2016 at 5:07 am
ThomasRushton (10/26/2016)
Eric M Russell (10/25/2016)
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
We've just identified a system in place here that has a we-can't-be-bothered-to-figure-out-how-to-use-NULL-properly-and-we're-never-going-to-see-this-date bug that's less than a decade away. This system is using an unknown date substitute of 2025-12-31.
Now, nine years *should* be long enough to migrate away from this particular POS, but Murphy and Parkinson (particularly Parkinson) are strong in this place...
Many years ago 01/01/2020 was chosen as a placeholder for an indefinite end date. The thinking was by that stage we'd have a completely new system in place and either a different way of handling these end dates or we'd picked something much further down the line to use in the same way. It might still be 3.5 years away but people are now getting twitchy about the likelihood of us still being on the same systems and having to change this date ina lot of places.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
October 26, 2016 at 5:19 am
BWFC (10/26/2016)
ThomasRushton (10/26/2016)
Eric M Russell (10/25/2016)
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
We've just identified a system in place here that has a we-can't-be-bothered-to-figure-out-how-to-use-NULL-properly-and-we're-never-going-to-see-this-date bug that's less than a decade away. This system is using an unknown date substitute of 2025-12-31.
Now, nine years *should* be long enough to migrate away from this particular POS, but Murphy and Parkinson (particularly Parkinson) are strong in this place...
Many years ago 01/01/2020 was chosen as a placeholder for an indefinite end date. The thinking was by that stage we'd have a completely new system in place and either a different way of handling these end dates or we'd picked something much further down the line to use in the same way. It might still be 3.5 years away but people are now getting twitchy about the likelihood of us still being on the same systems and having to change this date ina lot of places.
Somewhere where I have worked used 01/01/9999 as an unspecified date. It has a reasonable distance away, however, there are a few places where devs and DBAs have used 31/12/9999. I still think that NULL is the perfect solution for this. They were trying to represent when there was no date or that date had yet to be specified. My inner voice screams "NULL!!!" and if I could I would have listened to it.
Please let me know if you disagree.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 26, 2016 at 5:29 am
Gary Varga (10/26/2016)
BWFC (10/26/2016)
ThomasRushton (10/26/2016)
Eric M Russell (10/25/2016)
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
We've just identified a system in place here that has a we-can't-be-bothered-to-figure-out-how-to-use-NULL-properly-and-we're-never-going-to-see-this-date bug that's less than a decade away. This system is using an unknown date substitute of 2025-12-31.
Now, nine years *should* be long enough to migrate away from this particular POS, but Murphy and Parkinson (particularly Parkinson) are strong in this place...
Many years ago 01/01/2020 was chosen as a placeholder for an indefinite end date. The thinking was by that stage we'd have a completely new system in place and either a different way of handling these end dates or we'd picked something much further down the line to use in the same way. It might still be 3.5 years away but people are now getting twitchy about the likelihood of us still being on the same systems and having to change this date ina lot of places.
Somewhere where I have worked used 01/01/9999 as an unspecified date. It has a reasonable distance away, however, there are a few places where devs and DBAs have used 31/12/9999. I still think that NULL is the perfect solution for this. They were trying to represent when there was no date or that date had yet to be specified. My inner voice screams "NULL!!!" and if I could I would have listened to it.
Please let me know if you disagree.
I don't disagree at all that NULL should be the way to go and when\if we migrate to a new system, the chances are that NULL will be what is used. In our situation though, a change in legislation meant that something that had to have an end date by law, could be left open indefinitely. The system wasn't set up to allow NULL so a placeholder had to be chosen. Maybe a longer date should have been chosen but when 01/01/2020 was picked, no one could have even remotely foreseen what happened subsequently and the situation in which we've now found ourselves.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
October 26, 2016 at 5:47 am
BWFC (10/26/2016)
...Maybe a longer date should have been chosen but when 01/01/2020 was picked, no one could have even remotely foreseen what happened subsequently and the situation in which we've now found ourselves.
I am not convinced that an arbitrary date would ever be a reasonable decision. I would have argued this one all day. In this scenario, why not just use the maximum? Or even the minimum? (as NULL could not be used)
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
October 26, 2016 at 5:59 am
Gary Varga (10/26/2016)
BWFC (10/26/2016)
...Maybe a longer date should have been chosen but when 01/01/2020 was picked, no one could have even remotely foreseen what happened subsequently and the situation in which we've now found ourselves.I am not convinced that an arbitrary date would ever be a reasonable decision. I would have argued this one all day. In this scenario, why not just use the maximum? Or even the minimum? (as NULL could not be used)
Again, you're preaching to the choir đŸ™‚ I don't know why they didn't go with the maximum date. Using the minimum would certainly have caused problems though. At that stage, it wasn't a decision into which I had any input. It actually made our lives, at the coalface as I was then, considerably easier when the indefinite dates were brought in.
How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537
October 26, 2016 at 7:46 am
Jeff Moden (10/25/2016)
Eric M Russell (10/25/2016)
Marcia J (10/25/2016)
I remember in the late 80's saying that the 2-digit year would be a problem and getting the message from other programmers, "So what? I'll be at another company by then."So yes, we often did do it to ourselves.
Those of us who have used the SMALLDATETIME datatype, we'll either be dead or gone fishing by 2079-06-06.
I hope you live until then and... I hope the last voice you hear is mine. đŸ˜€
There are a many data types and attributes like: MONEY, XML, Age TINYINT, Sex CHAR(1), and INT IDENTITY that won't scale to 2079.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
October 26, 2016 at 1:10 pm
So as long as we're planning for floods we should be good against seltzer on the server racks?
October 27, 2016 at 9:21 am
ZZartin (10/26/2016)
So as long as we're planning for floods we should be good against seltzer on the server racks?
Not sure on that one.
I for one was trying to get a feel for what to do when BOTH the clownpocalypse and zombiepocalypse happened on the same day. Do you stay with your original plan and support the clowns in taking down the zombies? or find a way to turn the clowns into zombies and THEN execute on the DR plan?
----------------------------------------------------------------------------------
Your lack of planning does not constitute an emergency on my part...unless you're my manager...or a director and above...or a really loud-spoken end-user..All right - what was my emergency again?
October 27, 2016 at 9:37 am
Matt Miller (#4) (10/27/2016)
ZZartin (10/26/2016)
So as long as we're planning for floods we should be good against seltzer on the server racks?Not sure on that one.
I for one was trying to get a feel for what to do when BOTH the clownpocalypse and zombiepocalypse happened on the same day. Do you stay with your original plan and support the clowns in taking down the zombies? or find a way to turn the clowns into zombies and THEN execute on the DR plan?
School boy mistake. Let them whittles each others numbers down then send in the mimes to finish the rest off.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 16 through 30 (of 42 total)
You must be logged in to reply to this topic. Login to reply