| Tables, Fields and Selectors - part 2 |
| Part of the "Working With QuSheet" tutorial for QuSheet |
| Part of the "Working With QuSheet" tutorial for QuSheet |
| Summary |
When choosing values for a Field in a Selector, “Sort” can specify whether unique values should be used or not. This is generally what is required since having a Field repeat with the same value more than once is likely to just produce exactly the same results two or more times. |
When more than one Field is set within a Selector, the Selector combines all values of all Fields to produce sets of values covering all possibilities. This can be rather inefficient – it makes sense to pull values for Fields from target tables rather than straight lists of default Field values. |
A: Two changes here affect Selector processing. One, prior to searching a table for field values, the required field is set to undefined so that it does not affect the searching of that table. Two, if a field is specified in a non-field-access heading entry then that field is set to the current running total prior to Selector processing / searching taking place. |
E: The problem that I describe with the “select pastime from winter” line selecting “months” from the summer table would not actually happen any more, since any current value for the months field (in the example, “december”) will be cleared before the look up takes place. |
A: Selectors can now specify a "filter in" or "filter out" line, which will take all the fields currently defined and cross-check them against a table (and field within a table if necessary) to determine what combinations should be allowed in and which not. |
Selectors are the fundamental mechanism used to make QuSheet data-driven – i.e. an advanced user can set up the Headings and another user can just fill in Tables and Fields (as with the Quick Win scenarios). |
| Summary » |
| View (duration 15m30s) |
| You will need to view this page on a non-handheld screen to see the presentation. |
| Addenda / Errata |
A: Two changes here affect Selector processing. One, prior to searching a table for field values, the required field is set to undefined so that it does not affect the searching of that table. Two, if a field is specified in a non-field-access heading entry then that field is set to the current running total prior to Selector processing / searching taking place. |
E: The problem that I describe with the “select pastime from winter” line selecting “months” from the summer table would not actually happen any more, since any current value for the months field (in the example, “december”) will be cleared before the look up takes place. |
A: Selectors can now specify a "filter in" or "filter out" line, which will take all the fields currently defined and cross-check them against a table (and field within a table if necessary) to determine what combinations should be allowed in and which not. |
| Addenda / Errata » |
| « Summary |
When choosing values for a Field in a Selector, “Sort” can specify whether unique values should be used or not. This is generally what is required since having a Field repeat with the same value more than once is likely to just produce exactly the same results two or more times. |
When more than one Field is set within a Selector, the Selector combines all values of all Fields to produce sets of values covering all possibilities. This can be rather inefficient – it makes sense to pull values for Fields from target tables rather than straight lists of default Field values. |
A: Two changes here affect Selector processing. One, prior to searching a table for field values, the required field is set to undefined so that it does not affect the searching of that table. Two, if a field is specified in a non-field-access heading entry then that field is set to the current running total prior to Selector processing / searching taking place. |
E: The problem that I describe with the “select pastime from winter” line selecting “months” from the summer table would not actually happen any more, since any current value for the months field (in the example, “december”) will be cleared before the look up takes place. |
A: Selectors can now specify a "filter in" or "filter out" line, which will take all the fields currently defined and cross-check them against a table (and field within a table if necessary) to determine what combinations should be allowed in and which not. |
Selectors are the fundamental mechanism used to make QuSheet data-driven – i.e. an advanced user can set up the Headings and another user can just fill in Tables and Fields (as with the Quick Win scenarios). |
| « Addenda / Errata |
A: Two changes here affect Selector processing. One, prior to searching a table for field values, the required field is set to undefined so that it does not affect the searching of that table. Two, if a field is specified in a non-field-access heading entry then that field is set to the current running total prior to Selector processing / searching taking place. |
E: The problem that I describe with the “select pastime from winter” line selecting “months” from the summer table would not actually happen any more, since any current value for the months field (in the example, “december”) will be cleared before the look up takes place. |
A: Selectors can now specify a "filter in" or "filter out" line, which will take all the fields currently defined and cross-check them against a table (and field within a table if necessary) to determine what combinations should be allowed in and which not. |
-> output produced by QuSheet, licenced to "Richard Develyn", 15 Oct 2009 130|1|24094