Within most of the Infinity database catalog tables, the NAME column contains a unique index which enforces a unique value within the NAME column for each row in the table. The NAME column within a catalog table is populated via the Name attribute for a specific spec type.
When a catalog item is loaded, a row is added to the appropriate catalog item table that contains the XML definition of that spec. For example, it you load a TableSpec, a row is added to the TABLECATALOG table. If you load a QueryViewSpec a row is added to the QUERYVIEWCATALOG. This row contains a good deal of information about the spec as well as the entire spec XML. It is often useful to examine this data when troubleshooting issues. The metadata within these catalog tables are used to populate the feature metadata pages.
Let’s take a look in the database at one at the catalog tables used to hold the metadata for datalists. Within SQL Server Management Studio, I start by filtering the Tables folder within the appropriate database:
We filter the table names that contain the word CATALOG:
The result is a filtered listing of tables that contain the work CATALOG. When a particular spec is loaded to form a feature, the metadata for the spec lands in the appropriate catalog table.
Since we want to inspect the table that holds the metadata for datalists, let’s browse the the DATALISTCATALOG Table:
Now, let’s take a look at the indexes on the DATALISTCATALOG table:
Most catalog tables contain a unique index on the Name column to enforce a unique name for the feature. Future product feature names could possibly conflict with your custom feature name. Therefore it is important that you provide a name that wont conflict with future features authored by Blackbaud. Blackbaud professional services typically adds the words “(custom)” to the end of each name. This will allow for easy identification of whether the spec was written by products, or services, as well as, guarantee a unique feature name.
Note: The only exception to the “(custom)” name rule should be Task specs, Functional areas and Query Views. There is no unique constraint on these from a database perspective and it doesn’t make sense from a UI standpoint to have the word “(custom)” in there.
For more information, see the following articles: