Is it acceptable to add custom values in T_DEFAULTS with a certain naming convention for the default name? I'm writing a custom function to return phone numbers in a v11-compatible way, and we have some preferred phone types we want to make a higher priority than others in the ranking. I'd prefer to store those values in a defaults type of table rather than hard code them.
I can create my own custom table, but would prefer to use T_DEFAULTS If that's acceptable.
Thanks,David
I was just looking for the answer to the same question, and found this:
http://www.tessituranetwork.com/network/Learning/Tessitura%20Knowledgebase/System%20Tables/Other/15209.aspx
I'm not sure what "As long as the parent table is unique" means, though...
What did you end up doing?
UPDATE (a few minutes later): Based on some of the other documentation I'm seeing, the Parent Table value is mainly so that in a consortium environment different organizations can have different defaults. I assume that means that as long as you only have one Field Name per Parent Table, everything is fine. And it looks like in a non-consortium environment, you can use Impresario as the Parent Table.
Unknown said: UPDATE (a few minutes later): Based on some of the other documentation I'm seeing, the Parent Table value is mainly so that in a consortium environment different organizations can have different defaults. I assume that means that as long as you only have one Field Name per Parent Table, everything is fine. And it looks like in a non-consortium environment, you can use Impresario as the Parent Table.
I see that T_DEFAULTS looks at TR_ORGANIZATION for the "parent table" values. At our org that includes TNEW and TNMP as well as the usual Impresario and Impresario Web. I suspect if a custom value was entered here is could be used for custom T_DEFAULTS fields and would then be ignored by standard Tessitura/TNEW/Etc. code. Might be worth some experimentation: we had added a custom LTR_DEFAULTS table years ago to provide a sort of custom T_DEFAULTS, but perhaps that sort of thing could have been avoided.
The parent table is just a way of siloing values into groups. You can use it for consortia, but we also break out various operational groups as well. So we have "Impresario" for the default Tessitura stuff, "Tessitura Web" connected to our old website, we now have organizations for TN Social Ticketing and two separate TN Express Web sites, and we've always had a CPSMA, which we use for our internal custom values.
We use them to prevent hardcoding in a wide variety of places: SQL Server Agent Jobs, Utilities, Custom Headers and more. One of my favorite uses is setting the seasons for EIS_IMP_CHANGED_LOAD_NEW, which is otherwise a pain to remember, find and fix each fiscal year. Also dbo.fs_get_default_value is your friend, if you haven't found it yet.
Gawain--
You say you have an organization called "CPSMA" for your internal custom values. Is that necessary, or just your preferred solution for making it easy to distinguish between custom and standard? I had been thinking of using Impresario as my Parent Table value and prefixing the names of my custom values with "NYP_", especially since it looks like TR_ORGANIZATION has implications for security settings. But if it's better or necessary to set up a separate TR_ORGANIZATION I can certainly do that.
-Galen
Good question. We have Impresario as our default organization on all groups: the CPSMA flagged T_DEFAULTS rows are only used by our own custom scripts. As I understand it you could, for a consortium, create copies of all of the Impresario values under a different organization, then set a security group to that organization, and that user would apply all of those values to their client sessions were relevant. But it certainly wouldn't stop you from running a report or utility which referenced a different organization's values. Our web user group, for instance, defaults to Impresario as well, even though all relevant information in that table for the API server is under the "Tessitura Web" organization. So my advice would be to go ahead and use a separate "organization" to more easily sort and separate the rows.