At KBC we have 10 reasons why we implement the 'Ultimate Generic Date/Time'-framework in every universe we create.
1. It provides the end-user the same look and feel (and way of working) for all the universes he uses. (click to enlarge the thumbnail images)
2. Once learned, how to create a between clause with a [Begin Range]- and [End Range] object from the Generic Date/Time-class, the user can get an answer to all his date/time related questions.
3. No index drop! In the past the universe designer probably implemented extra derived objects (based on the original date-field) like year(), month(),...to be used in year/month related interval queries. But as a consequence, the query will not use the provided date-field index, and slow performance will annoy the end-user. With the framework, all time-related interval-questions can be done against the original-indexed-date-field.
4. Starting from the provided template universe a designer can easely implement customized predefined date-filters.
5. Only a few copy/paste steps are necessary to implement the framework in a target universe (less than 3 minutes)
6. An adhoc list-of-values with date/time intervals can be presented to easely select a date/time range.
7. 'Current date'-awareness: all objects (and the adhoc list-of-values) are 'current date' aware, in other words, at the moment you refresh the dataprovider, they are calculated starting from the current database system datetime.
8. Only one stand-alone derived table in the universe (using a dummy table like DUAL -Oracle- or SYSIBMY.SYSDUMMY1 - DB2) is needed to implement the adhoc list-of-values date ranges.
9. Can easely be used for scheduling the same report with other date-intervals (just change the prompt!)
10. A user-preference and platform independant solution for entering date-prompts is available.
Do you want to see a video, navigate to screencast
Learn more on how to implement the framework, navigate to the post 'How to implement the 'Ultimate Generic Date/Time' framework'
3 Comments
