Database View shows old reference display value after fix script update

[js222359]

I’m running into an issue with a database view showing a stale reference display value after a fix script. I updated a list type field (Network) on a custom table via a fix script. The Network column is being treated like a reference on the database view. The record form shows the correct, updated value. The database view list still shows the old display value. List refresh, cache flush, and re-querying the view do not resolve it. Also re-saving the record does not refresh the value in the view.

[Matthew_13]

Yes indeed;

 This usually comes down to one of two things with database views plus Glide List fields:

1) The DB view is not showing your field; it’s showing the joined display

Even though the form reads the Glide List field directly, a DB view often ends up showing a joined value or a different alias/column and that join can still be pointing at the “old” relationship.

Quick test you can do:

• Open a record from the DB view list and use Show XML or add the field and check the raw value.

• Also try hitting the view list with sysparm_display_value=false in the URL.

  • If the raw sys_id list is old in the DB view but new on the base table, the DB view is pulling from the wrong place (join/alias).

My Recommendation:

• Go to System Definition → Database Views → <your view>

• Confirm the Network column is mapped to the correct base table + field, not a joined display field.

• Use the related link to Regenerate / Rebuild the view definition or remove/re-add the element in the view.

• Re-save the DB view.

2) Your fix script updated the Glide List column, but didnt update the underlying list relationship table

A Glide List isn’t a true reference field; its a string of sys_ids plus internal handling. If the script updated the field in a way that bypassed normal processing bulk update patterns, direct DB update, you can get weird “looks right on form, stale elsewhere” symptoms.

What to check

• In your fix script: did you do something like direct SQL, setValue() with a comma string, or updateMultiple()

• If yes, re-run using a normal GlideRecord update per record.

Safe pattern

• Query each record

• Set the glide list field normally

• Call update() (avoid updateMultiple for this)

The gotcha:

If your DB view uses a join to the Network table and expects one value, but your field is a list, the view will pick one or reuse a previously resolved display value depending on how the join was built. That can look like stale display.

@js222359 - Please mark as Accepted Solution and Thumbs Up if you found Helpful!!

[js222359]

@Matthew_13 I've confirmed the network column is correctly mapped to the correct base table. I've also tried the related "try it" link to regenerate/rebuild the view definition and still no change to the network column on the database view. I have also confirmed the fix script, I have not done anything like setValue(). 

One thing to note is I am working with two different instances in which, instance x I have not observed this issue and running the fix script against the custom table automatically refreshed the network column on the database view, but when running the same actions on instance y, this is where the issue is occuring. I have done a comparison between the two instances and nothing is different between the two instances. 

[Matthew_13]

Check these on instance Y:

1. Look at sys_db_view_table_field for the view and confirm the network column is coming from the expected table element. If those records are stale or duplicated, the column won’t refresh.

2. Make a real rebuild by renaming the database view to _tmp, save, rename back, and save again.

3. Flush cache or test after a node switch—Y may still be serving an old metadata cache.

Most cases like this come from view field collision or stale sys_db_view_table_field records, even when the UI looks identical.

@js222359 - Please mark as Accepted Solution and Thumbs Up if you found Helpful!!

[js222359]

@Matthew_13 Have confirmed from the network column is correctly coming from the expected table element in sys_db_view_table_field. Also attempted the rebuild by renaming and then reverting back after saves, still no changes. The flush cache also had no impact.