June 26, 2014 at 8:15 am
Gail, your post got me laughing out loud (literally) this morning. My coworkers are all moving away from me now. Apologies for adding absolutely nothing useful to the thread
June 26, 2014 at 10:51 am
Varchar date columns. We do BI off a widely-used call center workforce scheduling system, where dates are commonly stored as varchar. Had an ETL failure this week - the date 9/30/3014 overflowed when converted to smalldatetime. In the application client the date is entered by a combination of calendar date picker and a formatted date field . . . displayed as MM/DD/YY. When manually editing an existing date it's easy to type into the wrong part of the date field and convert 9/30/2014 to 9/30/3014 -- which is invisible once the user has tabbed out of the field because both will display as 9/30/14. There's no error-checking, so the system is happy to schedule the employee for the same repeating task every Friday for the next thousand years (it's suspected that at some point schedule compliance will suffer -- they're scheduling people, not forecasting geologic events). We thought we were covered by smalldatetime handling dates through June 2079, but needed to add ETL error-handling for this case.
June 26, 2014 at 1:24 pm
Randy Rabin (6/26/2014)
Gail, your post got me laughing out loud (literally) this morning. My coworkers are all moving away from me now.
And so it begins...
Gail Shaw
Microsoft Certified Master: SQL Server, MVP, M.Sc (Comp Sci)
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability
Viewing 3 posts - 31 through 32 (of 32 total)
You must be logged in to reply to this topic. Login to reply
This website stores cookies on your computer.
These cookies are used to improve your website experience and provide more personalized services to you, both on this website and through other media.
To find out more about the cookies we use, see our Privacy Policy