During holidays generation, Q++Studio creates a local holidays table on your PC, which contains only the holidays occurrences, of all the holidays rules in your database.
the generated holidays table
temporary holidays table generated at the beginning of diary generation
Then, during diary generation, Q++Studio creates a local holidays table on your PC, which contains only the holidays occurrences that are related to the aeiou-Holidays you are using, combined with the names of the recurring holidays and one-time-dates (this is where one-time-dates are combined with recurring holidays).
The advantage is that this makes for much faster look-up of holidays during diary generation, and frees up network bandwidth for other users. The downside is that if Q++Studio "forgets" to bring in holidays for a given Holidays Set, your diary will generate as if there were no holidays defined for it (and you will not get an error message).
Usually this is done automatically as Q++Studio scans the list of tokens looking for references to aeiou-Holidays, and emits design-time messages to alert you if a Holidays List was referred to but not defined. However in some cases, usually if you refer to specific Holidays Sets ID's in a Macro, Q++Studio will not be able to notice that the referred to Holidays Set is not included in the temporary table.
Ordering of Holidays
As seen above, when you generate holidays, Q++Studio creates a table of holidays occurrences (as opposed to holidays rules), and then, during diary generation, Q++Studio creates a local holidays table on your PC, which contains only the holidays occurrences that are related to the aeiou-Holidays you are using.
In the expanded sample below, the first fields of the holidays database are displayed to show how holiday occurrences are ordered by Q++Studio, when multiple holidays and/or one-time dates occur on the same date and possibly even for the same holidays list.
expanded view of the temporary holidays table
Date |
The dates of the generated holidays occurrences are grouped together (a). This sorting criterion is of no importance for single-date holidays tokens such as [fa]..[fu], but it makes a difference for duration tokens such as [fa:m+00]. |
Country_ID |
Then all occurrences of the same holidays set counter value are grouped (b). This is the position, in the aeiou-holidays list, of the holidays set to which the holiday occurrence belongs to. This means that you are assured that, for example, a-holidays will appear in the order that holidays sets were listed in a-Holidays. |
Priority |
Occurrences of the same date and holidays set are then grouped by priority (c1 and c2), which is a property of each holiday rule and one-time-date, allowing you to define the order of appearance of multiple holidays on the same date. |
Holiday_ID |
Finally, in the even rarer case when the Date, the Counter, and the Priority are the same, then the determining criterion is the Holiday ID, which roughly corresponds to the chronological order in which the holidays were created. This is clearly an unreliable way to sort holidays, and you should always set the priority of holidays that may occur on the same date as another holiday of the same holidays set. |
OneTimeDate |
The OneTimeDate criterion is not really used for sorting but is one of the criteria available to inspect in the holidays macro functions. |
Note that this date is saved as the number of days since December 30th 1899, which is an IT standard.
Topic 150500, last updated on 12-Jul-2022
