Note: For purposes of this tech note, any instance of Strategy Desktop 9.0.x to 9.4.0 will be referred to as Developer, the equivalent product offering in the 9.4.1 platform.
SYMPTOM:
When a user tries to add a partition level to a Partition Mapping Table object using Strategy Developer, the following error is thrown:
Sample Code/Error
No partition level attribute candidates were found
Upon checking the structure of the Partition Mapping Table and of the attribute which the user wants to add as the partition level, it is noticed that the column used to partition the Partition Mapping Table has the same name as a column used by the ID attribute form of the attribute that the user desires to add as the partition level. Therefore, there should be at least one partition level attribute candidate.
STEPS TO REPRODUCE
1) Create the following three tables using DB Query tool:
create table DAY (date_Id datetime)
create table DATA (Row_Date datetime, identifier int)
create table PMT_DATA (Row_Date datetime, PBTNAME varchar(100))
2) Importe all three tables into the Warehouse Catalog of any Strategy 9.x project;
3) Create attribute Day. Map the ID form to the following two expressions:
4) Open the PMT_DATA partition mapping table object, and try to add a partition level attribute, a message pops up saying there are no candidates. However, attribute Day should be a candidate.
CAUSE:
This is a known issue where Strategy 9.x. Partition Mapping Tables can only consider an attribute as a candidate to be the partition level when the name of the column used to partition the Partition Mapping Table matches the name of the expression of the table defined as the lookup table of the ID form of the attribute when the ID form is created (or saved).
In order for an ID form to be a candidate, the column available in the PMT must be the same column used as the ID form expression of the attribute which was created first. In this event, date_Id was created first but does not match any available columns in the PMT, so the attribute is not considered a candidate.
ACTION:
Contact Strategy Technical Support for an update on the status of this issue.
WORKAROUND:
There are two ways to work around this issue, they will be described using the example above:
Method #1
1. Change the PMT_DATA tables, so that it has the following structure:
PMT_DATA (date_Id datetime, PBTNAME varchar(100))
Method #2:
1. Edit attribute Day, make table DATA the lookup table for the ID form and delete the date_Id expression;
2. Save and close attribute Day;
3. Reopen attribute Day, re-add expression date_Id and set table DAY as the primary table.
4. Open the PMT_DATA object, now Day will show up as a partition level attribute candidate.
Method 2 essentially recreates the date_Id form expression so that the first created form expression left in the attribute is the Row_Date form expression which will then allow the attribute to be an eligible candidate of the PMT.
