asked on In T-SQL how to handle [Expiration Date] = 'perpetual' or 'month-to-month' or 'dates vary'
I've been given 13 different spreadsheets that are currently used for tracking our companies contracts. They look like they were created by 13 different monkeys. No consistency between them, no data consistency within each one, multiple data stored in single fields. Those are the least of the issues with these Excel sheets. I have to import them into a MS SQL Server 2008 R2 table. /rant
Anyway... First question: Given the [Excel] column "Expiration Date" and understanding that this date [in the db table] is used in a PowerShell script to send an email alert to the contact person x days prior to the contract expiring:
How would you handle the following text entries from the spreadsheet in that date column with respect to what exactly should go into the date column and how would the various conditions be handled for the expiration warning alert message?
I hate using date "codes" like 1/1/1900 or 12/31/9999 to represent information in a data field and I doubt if the users of the database once it's done would be able to manage that complexity.
How would you handle this? Thanks!
Anyway... First question: Given the [Excel] column "Expiration Date" and understanding that this date [in the db table] is used in a PowerShell script to send an email alert to the contact person x days prior to the contract expiring:
How would you handle the following text entries from the spreadsheet in that date column with respect to what exactly should go into the date column and how would the various conditions be handled for the expiration warning alert message?
Entries in "Expiration Date" column:
"6/30/2017" <-- That one is good. ;-)
"month to month"
"perpetual"
"expiration dates vary"
"12 month subscription"
I hate using date "codes" like 1/1/1900 or 12/31/9999 to represent information in a data field and I doubt if the users of the database once it's done would be able to manage that complexity.
How would you handle this? Thanks!
Microsoft SQL ServerSQL
Last Comment
Scott Pletcher
ASKER
Just the 'Contract Expiration Date' column. I'll have to have conversations with the owners of the spreadsheets. After a recent conversation "perpetual" sometimes that it is "auto renewing" but may not be "indefinite." Answers that they will have to provide to me.
You are right; I don't think this is going to be solved with a WHERE clause. The data is going to have to be cleaned up by the people who what they meant. Thank you for your input.
You are right; I don't think this is going to be solved with a WHERE clause. The data is going to have to be cleaned up by the people who what they meant. Thank you for your input.
ASKER CERTIFIED SOLUTION
THIS SOLUTION ONLY AVAILABLE TO MEMBERS.
View this solution by signing up for a free trial.
Members can start a 7-Day free trial and enjoy unlimited access to the platform.
You need to add an (internal) tinyint column to the table to store a code representing the [Expiration Date] (ED). Thoroughly analyze the ED one time when it is initially entered, assign the code and then use the code from then on. Having to analyze the ED every time you check it will be cost prohibitive.
My preference would be for a trigger to analyze it, upon INSERT or UPDATE, but the trigger needs to be written efficiently, and must be able to log something to notify someone if a truly bad value is entered. The sooner to the time of entry that it's corrected the easier the correction will be.
My preference would be for a trigger to analyze it, upon INSERT or UPDATE, but the trigger needs to be written efficiently, and must be able to log something to notify someone if a truly bad value is entered. The sooner to the time of entry that it's corrected the easier the correction will be.
ASKER
Icohan, thanks, I'll see if I can use the CASE WHEN with the existing data from the spreadsheets. The owner of the spreadsheets is now doing some cleanup of those sheets. We'll see what they look like once she's done. ;-)
ScottPletcher, that does sound like a more efficient way to do the expiration checks. Would checking the expiration date one time and assigning it an integer code also allow for updating the date once it expires and is renewed with a new date. Most of these contracts are one to three years in length and are then renewed for another "term."
How would you "code" an expiration date as an integer? Would you use number of days from a fixed reference date?
ScottPletcher, that does sound like a more efficient way to do the expiration checks. Would checking the expiration date one time and assigning it an integer code also allow for updating the date once it expires and is renewed with a new date. Most of these contracts are one to three years in length and are then renewed for another "term."
How would you "code" an expiration date as an integer? Would you use number of days from a fixed reference date?
The tinyint would simply be a code that represents a very-clearly-defined "EXpiration Date", i.e., with very clear rules about it works.
Sample "Expiration_Date_Code" column values with
Explanation:
1 = "6/30/2017"
A specific, valid date was entered; this date will be used as the exp date
2 = month to month, for a fixed period of time
Expiration date is the same day every month, for a fixed number of months/years
92 = month to month, "forever"/until cancelled
93 = perpetual
?
8 = expiration dates vary
?
? = "12 month subscription"
"12 month subscription" might become a type 2, with a one year fixed time period.
So, upon initial INSERT of the row, and for any UPDATE of "Expiration Date" (ED) afterward, the value is analyzed, matched to the available naming patterns, and a code assigned. If the ED can't be converted to a code, then an error is raised immediately by whatever method you want to use.
Sample "Expiration_Date_Code" column values with
Explanation:
1 = "6/30/2017"
A specific, valid date was entered; this date will be used as the exp date
2 = month to month, for a fixed period of time
Expiration date is the same day every month, for a fixed number of months/years
92 = month to month, "forever"/until cancelled
93 = perpetual
?
8 = expiration dates vary
?
? = "12 month subscription"
"12 month subscription" might become a type 2, with a one year fixed time period.
So, upon initial INSERT of the row, and for any UPDATE of "Expiration Date" (ED) afterward, the value is analyzed, matched to the available naming patterns, and a code assigned. If the ED can't be converted to a code, then an error is raised immediately by whatever method you want to use.
If not then in my opinion is impossible to "translate" int SQL WHERE clause something like "month to month"...
Maybe "perpetual" is also "good" as that means in my (poor) English this never expire as long as Customer.valid=true but anything else is a joke in my opinion without a "contract start date" or "contract effective date" datime column.