*** This version of Confluence is for testing only and contains a copy of content from June 29th 2026. No changes will be preserved. ***
-
Created by
Sharon Helen Markus, last updated on Apr 13, 2026
4 minute read
Update as of 4-13-26:
The problem of multiple srs_ids in the marc__t table, discovered in November 2025, remains unresolved. We are working with Index data and our hosting team from EBSCO to resolve the issue. We have a new workaround in place that allows you to use records on the marc__t table in your queries more easily. We have created a derived table with multiple records removed that you can use in your Metadb reporting database queries.
Instead of using the folio_source_record.marc_ _ t table, you can point to the new derived table created daily to get your data from the MARC records in Metadb: local_derived.marc_ _ t
Update of 1-28-26:
The problem of multiple srs_ids in the marc__t table, discovered in November 2025, remains unresolved. The number of problem records is now over 282,000 instances. The workaround solutions described previously on this page for how to get the correct record from the marc__t table are no longer accurate. The following (new) method can be used in queries to select the correct record from the marc__t table:
Example: Find the values in the 050 field, and get the LC Class and LC Class number from the field.
- Note that you must find the MAX row number from the records_lb table, and join on marc__t.srs_id = records_lb.matched_id. This is a different join than the one described previously
- It is not necessary to specify state = 'ACTUAL' in the Where section of the query, since that condition no longer limits the results to the correct record (an instance can have multiple srs_id's that are all "ACTUAL")
SELECT
sm.instance_hrid,
sm.content AS lc_classification,
SUBSTRING (sm.content,'[A-Za-z]{0,}') as lc_class,
TRIM (TRAILING '.' from SUBSTRING (sm.content, '\d{1,}\.{0,}\d{0,}')) AS lc_class_number,
MAX (records_lb.__id)
FROM folio_source_record.marc__t AS sm
INNER JOIN folio_source_record.records_lb
ON sm.srs_id = records_lb.matched_id
WHERE sm.field = '050'
AND sm.sf = 'a'
AND sm.ord = 1
GROUP BY sm.instance_hrid, sm.content
------------------------------------------------------------------------------------------------------------------------------------
MARC _ _ t table issue: Multiple srs IDs associated with same instance ID
In the Metadb reporting database, the folio_source_record.marc__t table should have a unique srs_id associated with each instance ID. However, in early November 2025, the Reporting Team noticed that, for some records (which now varies daily from zero to thousands), there were multiple srs_ids associated with each instance_HRID. The multiples were older versions of the marc record, which normally would not appear in that table. The marc__t table should include only records where the state of the record is 'ACTUAL,' but it is including records where the state field is 'OLD.' So in queries that use the marc__t table, we are getting duplicate counts in those cases where the marc record has been updated and the old versions not purged. This issue came up before with LDP software, and it was fixed. There is code to address this issue for the Metadb software, but it is not clear that the code is working correctly. The Reporting Team is working with Index Data to address this problem.
Using 'ACTUAL' for Accurate Record Counts
In the meantime, you can use the record state of 'ACTUAL' as a workaround to make sure you are getting accurate record counts when you are using the folio_source_record.marc__t table.
Sample 1: – an example of code to use for your JOIN to filter on a record state of 'ACTUAL'
FROM folio_derived.instance_ext AS instext
LEFT JOIN folio_source_record.marc__t AS sm ON instext.instance_id = sm.instance_id
LEFT JOIN folio_source_record.records_lb AS rec ON sm.instance_id = rec.external_id
WHERE rec.state = 'ACTUAL'
Here is an example of a query that uses 'ACTUAL' :
-- The query finds records that have "disk" in the call number and gets multiple fields from the marc__t table.
https://github.com/cul-it/cul-folio-analytics/tree/main/metadb/canned_reports/MCR413
Here is an example of a query that shows two srs_id records that correspond to one instance record on the folio_source_record.marc _ _ t table along with the result. Note the join from the inventory table to the marc _ _ table. It isolates just one instance_hrid in the WHERE clause. The result shows one instance_hrid record associated with two srs_id records. One srs_id record shows a state of 'ACTUAL,' and the other shows a state of 'OLD'. This results in inflated record counts.
Sample 2 -- query shows a marc__t table instance_id with two srs_id's, one OLD and one ACTUAL:
SELECT DISTINCT
instance_ext.instance_hrid,
marc__t.instance_id,
marc__t.srs_id,
records_lb.state
FROM folio_derived.instance_ext
LEFT JOIN folio_source_record.marc__t
ON instance_ext.instance_id = marc__t.instance_id
LEFT JOIN folio_source_record.records_lb
ON marc__t.instance_id = records_lb.external_id
AND marc__t.srs_id = records_lb.id
WHERE instance_ext.instance_hrid = '11023049'
Result:
And if we wanted to show the WHERE condition “records_lb.state = ‘ACTUAL’ “ we could add it onto the same query as follows. Using 'ACTUAL' in the WHERE clause results in one srs_id associated with one instance_hrid. The count of records is no longer inflated.
Sample 3: query shows how to get just the ACTUAL version of the record:
SELECT DISTINCT
instance_ext.instance_hrid,
marc__t.instance_id,
marc__t.srs_id,
records_lb.state
FROM folio_derived.instance_ext
LEFT JOIN folio_source_record.marc__t
ON instance_ext.instance_id = marc__t.instance_id
LEFT JOIN folio_source_record.records_lb
ON marc__t.instance_id = records_lb.external_id
AND marc__t.srs_id = records_lb.id
WHERE instance_ext.instance_hrid = '11023049'
and records_lb.state = 'ACTUAL'
Result:
Related Tickets on this Issue
We are working with EBSCO and Index Data to resolve this issue. Here is the related ticket, for your reference:
Metadb Issues Log
https://github.com/metadb-project/metadb/issues/92