Acronis protects the complete Microsoft technology stack: Windows Server, Windows PC, laptop and Surface data; Microsoft business applications; Microsoft Hyper-V; Azure VMs; Microsoft Windows Server 2016; Microsoft Exchange 2016 and SQL Server 2016.
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!
[X]
Welcome to Experts Exchange
Add your voice to the tech community where 5M+ people just like you are talking about what matters.
- Help others & share knowledge
- Earn cash & points
- Learn & ask questions
2
2-
2
6 Comments
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.
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
How can IT departments tackle the challenges of a Big Data world? This white paper provides a roadmap to success and helps companies ensure that all their data is safe and secure, no matter if it resides on-premise with physical or virtual machines or in the cloud.
Question has a verified solution.
If you are experiencing a similar issue, please ask a related question
Ever needed a SQL 2008 Database replicated/mirrored/log shipped on another server but you can't take the downtime inflicted by initial snapshot or disconnect while T-logs are restored or mirror applied?
You can use SQL Server Initialize from Backup…
It is possible to export the data of a SQL Table in SSMS and generate INSERT statements. It's neatly tucked away in the generate scripts option of a database.
Via a live example, show how to shrink a transaction log file down to a reasonable size.
Viewers will learn how to use the SELECT statement in SQL to return specific rows and columns, with various degrees of sorting and limits in place.
Suggested Courses
Course of the Month11 days, 17 hours left to enroll
730 members asked questions and received personalized solutions in the past 7 days.
Join the community of 500,000 technology professionals and ask your questions.