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