There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.
Solved
In T-SQL how to handle [Expiration Date] = 'perpetual' or 'month-to-month' or 'dates vary'
Posted on 2016-09-28
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!
2
2-
2
6 Comments
Active today
Do you have ANY datetime column tied to the (customer) record to relate back to any of those entries?
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.
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.
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.
Active today
OK so if you have "Contract Expiration Date" as a date and certain strings stored in that "Expiration Date" column this can be still done using SQL CASE... syntax however those strings must be "unique" in a group - hope you understand what I am trying to say here.
Like they all must be like:
"12 month subscription" and NOT variations like "twelve month subscription" OR "12 months subscription" ETC for you to be able to build a CASE like pseudo code below:
...
CASE WHEN [Expiration Date] = "12 month subscription"
AND [Contract Expiration Date] - "12 mths" > getdate() - xdays
THEN -- send email
ELSE -- wait till next time check
END
.....
Like they all must be like:
"12 month subscription" and NOT variations like "twelve month subscription" OR "12 months subscription" ETC for you to be able to build a CASE like pseudo code below:
...
CASE WHEN [Expiration Date] = "12 month subscription"
AND [Contract Expiration Date] - "12 mths" > getdate() - xdays
THEN -- send email
ELSE -- wait till next time check
END
.....
Active today
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.
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?
Active today
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.
Featured Post
There are many ways to learn to code these days. From coding bootcamps like Flatiron School to online courses to totally free beginner resources. The best way to learn to code depends on many factors, but the most important one is you. See what course is best for you.
Question has a verified solution.
Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.
Have a better answer? Share it in a comment.
Join & Write a Comment Already a member? Login.
An alternative to the "For XML" way of pivoting and concatenating result sets into strings, and an easy introduction to "common table expressions" (CTEs).
Being someone who is always looking for alternatives to "work your data", I came across this …
Microsoft provides a rich set of technologies for High Availability and Disaster Recovery solutions.
Via a live example, show how to extract insert data into a SQL Server database table using the Import/Export option and Bulk Insert.
SQL Database Recovery Software repairs the MDF & NDF Files, corrupted due to hardware related issues or software related errors. Provides preview of recovered database objects and allows saving in either MSSQL, CSV, HTML or XLS format. Ensures recov…
Suggested Courses
Course of the Month4 days, 22 hours left to enroll
579 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.