I have been searching, with limited success, for documentation on how to add a custom table to the LDMS database that contains permanent information that will persist through LDMS/database upgrades and be available for editing through LDDA bar code web forms and for reporting through LDMS queries. I have found bits and pieces but nothing comprehensive. So far, I have found the following articles:
These articles all touch on the common topic of using an XML file along with the CoreDBUtil utility on the core server to add the data table, but I really want to understand the full topic to make sure that I construct a robust solution that is supported not just with LDMS 9.6 but also LDMS 2016 and beyond.
As a condensed description of the issue I am trying to solve, I am trying to create a table of asset-tracking information including physical device location (e.g. the office number), the first and last name of the person who owns the device (which is not necessarily the person who uses the device), the internal asset tag number assigned to the device, and service tag numbers of any monitors associated or connected to the device. The information will be entered or edited using bar code web forms created through LDDA, will persist throughout the life of the device entry in LDMS, will persist through LDMS upgrades, and the information will be available for inclusion in LDMS queries.
Some questions I have are:
What is the full schema reference for generating the table? Does the schema allow for indexed tables for efficient searches? Does the schema allow for many-to-one relations ships such as one device having multiple monitors? Does the schema change significantly over time? For example, the "Custom LDDA information permanent" article uses a version 188.8.131.52 schema while the "Show Extra Patch Related Columns in System Inventory" uses version 9.00.2.0.
Are the custom table changes warranted by LANDesk to survive a LDMS database upgrade? If so, what, if any, restrictions are there regarding in-place upgrades, for example? We depend heavily on this asset information for use with ALM, and if it were to vanish with a core server upgrade, the results would be disastrous. Would a data export followed by data import be required?