Page History

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. 

...

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' :

...

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