Configuring Geo SCADA Custom Inherited Metadata Fields

After the fix, each object resolves the closest configured group value while retaining its own explicit override. The reliable pattern is to separate the locally configured metadata from the effective inherited value, resolve parent precedence explicitly, and verify the result at the object and alarm-instance levels.

Why do the usual fixes fail?

Several tempting fixes attach the classification to the wrong part of the signal chain or create configuration that cannot remain valid as the database changes.

• Using a fake latitude and longitude: This forces an object into a geographic region, but the coordinates stop representing its actual location. A later requirement for real coordinates breaks the classification scheme.
• Using regions as logical groups: Geographic membership and operational ownership are different relationships. Equipment belonging to one logical area may not occupy one geographic region.
• Configuring AOI on every point: Point-by-point configuration duplicates data and makes a parent-level change expensive. Missed points retain stale or blank assignments.
• Changing alarm redirections: Redirection can affect the AOI associated with an alarm instance, but it does not create a general inherited field on database objects. It also couples metadata resolution to alarm behavior.
• Adding a calculation point to every group: An expression such as IIF(".MetadataField" <> {NULL}, ".MetadataField", "..MetadataFieldCalc") can select a local value or a parent calculation, but every group must contain and maintain the calculation object.
• Hard-coding relative parent paths: Expressions that climb a fixed number of parents fail when templates are nested differently or objects move. The configuration must know the hierarchy depth instead of resolving it.

Template expressions do not supply arbitrary dynamic inheritance for custom group metadata. In the configuration described, template-level assumptions were limited to properties such as Name, FullName, and Parent. Tuning expressions cannot repair a missing metadata relationship.

What is the real cause?

The requested behavior combines two different data models. The first is an explicit value configured on any object or group. The second is an effective value calculated by walking upward until a non-null value is found. Geo SCADA does not provide that custom parent-to-child field behavior out of the box for this use case, so the inheritance rule needs an explicit resolver.

Treat the hierarchy as a precedence chain. The object-level setting has highest priority, followed by its immediate parent, then successive ancestors. The first populated value wins. This is nearest-ancestor inheritance, not a bulk copy from one fixed group.

Keep the configured and resolved values distinct. For example, SetProperty can hold the optional local override, while SetPropertyInherit can hold or expose the resolved value. If both meanings occupy one writable field, a copied parent value becomes indistinguishable from an intentional local override and blocks later propagation.

Where does a wrong value enter the signal chain?

Trace the field from its source through the resolver to its consumer before changing configuration. Inspect the resolved records first; alarm displays and searches only show what the upstream relationship delivered.

Signal	Source	Wrong-value symptom	Diagnostic decision
Local metadata	Object or group property such as SetProperty	A child keeps an unexpected value after its parent changes	Determine whether the child contains a real local override or a previously copied parent value.
Ancestor identity	FullName hierarchy in CDBObject	A value comes from a distant ancestor or no ancestor is found	Check the full object path, delimiter relationship, and descending path-length ordering.
Resolved metadata	SQL lookup or scheduled Logic program	The configured parent is correct but the child remains blank or stale	Run the resolver directly and inspect its schedule, traversal order, and write result.
Alarm AOI	Configured Alarm AOI and possible redirection behavior	Object metadata is correct but an alarm instance shows another AOI	Inspect the alarm instance and its redirection path separately from the custom metadata.
Search key or view link	Consumer reading the effective field	Searches, default-view links, or alarm-view links use the wrong destination	Confirm that the consumer reads the resolved field rather than only the local field.

Which inheritance design should you choose?

Use an on-demand SQL lookup when a query, report, or integration needs the value and can resolve it during each read. This avoids copied state and reacts immediately when hierarchy or metadata changes. The cost is added query logic wherever the value is consumed.

Use a scheduled Logic program when existing consumers need a directly readable search-key field on every object. A single program can materialize the effective value daily or on another configured schedule. This makes downstream queries simple, but changes remain invisible until the next successful run.

Use per-group calculations only when the design already requires a calculation object in every group and its limited group-level reference is acceptable. The repeated object and expression configuration makes this a poor default for a large or changing hierarchy.

Do not substitute AOI for general metadata. AOI primarily serves alarm instances, whereas a custom inherited value may need to drive searches, display links, reporting, or device-level attributes in the same query.

How do you resolve the nearest configured ancestor with SQL?

Define a null representation before writing the query. Object references can use a clear null value more readily than integers. For a numeric field, choose a representation that cannot collide with a valid configured value, or store an explicit configured/not-configured state alongside it.

1. Read the target object's local metadata. If it is populated, return it as the effective value.
2. If the local value is null, search CDBObject for ancestor paths whose metadata is populated.
3. Order matching ancestors by LEN(FullName) in descending order.
4. Return TOP(1). The longest matching path is the closest populated ancestor.

SELECT TOP(1) FullName, MyMetaField
FROM CDBObject
WHERE MyMetaField <> {NULL}
  AND {MyObjectFullName} LIKE FullName || '.%'
ORDER BY LEN(FullName) DESC

Replace MyMetaField, {NULL}, and {MyObjectFullName} with the actual field, its null representation, and the target object's full name. Select the same metadata property tested in the WHERE clause; using MyField in one location and MyMetaField in another would return the wrong column or fail.

The path predicate searches ancestors rather than the target object itself because it requires the candidate FullName plus a dot and descendant suffix. That is why the procedure checks the local value before executing the ancestor query. Without ORDER BY LEN(FullName) DESC, TOP(1) does not express nearest-parent precedence.

How do you materialize inheritance with scheduled Logic?

Where metadata cannot evaluate the required expression directly, implement the resolved value as a string variable, constant, reference, or suitable field that one Logic program updates. Keep the optional explicit metadata separate.

1. Start at the highest configured group and carry its effective value into the traversal.
2. For each object, read its explicit local field. If populated, make it the effective value for that object and its descendants.
3. If the local field is blank, use the effective value carried from the parent.
4. Compare the calculated value with the current resolved field.
5. Write only when the values differ. This avoids repeated configuration writes when nothing changed.
6. Record or expose run status so operators can distinguish a blank inherited value from a resolver that did not complete.

A top-down traversal prevents a child from reading stale parent output during the same run. If the implementation instead performs independent lookups, apply the same longest-path rule used by the SQL method.

The schedule defines the maximum propagation delay. A daily run can leave a new group assignment, moved object, or cleared override stale until the next execution. Select the schedule from the business tolerance for stale search keys or links; no fixed interval applies to every database.

How do you verify the result and prevent regressions?

Build a small hierarchy that exercises precedence rather than testing one successful child. Use a root group with a value, an intermediate group with another value, descendants with blank fields, and one object with an explicit override.

1. Confirm that a blank child inherits the closest populated parent.
2. Confirm that an intermediate-group override replaces the root value only for its descendants.
3. Confirm that an object-level override remains unchanged after the resolver runs.
4. Clear the object override and confirm that parent inheritance resumes.
5. Clear the nearest group value and confirm that resolution falls back to the next populated ancestor.
6. Move a test object between groups. SQL resolution should follow its current FullName; a materialized field should change after the scheduled program runs.
7. Run the program again without configuration changes and confirm that it performs no unnecessary value writes.
8. Query the final consumer and verify that it reads the resolved property in the same request, without repeated ParentGroupId traversal.

For AOI-related symptoms, trigger or inspect the relevant alarm instance after validating the object metadata. A correct custom field does not prove that the alarm instance uses the same AOI because configured Alarm AOI and redirections form a separate path.

FAQ

Stop and escalate to official Geo SCADA support when the installed release evaluates the path query differently, required properties cannot be written through the supported Logic or API interface, or alarm-instance AOI remains wrong after object metadata and redirections have been verified. Provide the product version, a minimal object hierarchy, the exact query or Logic expression, and the observed versus expected resolved values.