Ah - that makes so much sense. The database functions evergreen.maintain_control_numbers() and evergreen.maintain_901() need to be invoked to ensure that the 003 field and 901 $c subfield exist in each authority record. I didn't hit that when I loaded your sample records because, of course, when I imported them into a shiny new 2.0 database these functions were invoked at import time so it changed the records to suit.
A SQL statement that would hit every record in authority.record_entry to ensure that these functions get invoked would be "UPDATE authority.record_entry SET active = active WHERE 1 = 1;". Maybe overkill, but better safe than sorry.
Also - clearly I should add some defensive coding to the authority interfaces to handle the case where the authority record does not have a 901 $c or 003!
Ah - that makes so much sense. The database functions evergreen. maintain_ control_ numbers( ) and evergreen. maintain_ 901() need to be invoked to ensure that the 003 field and 901 $c subfield exist in each authority record. I didn't hit that when I loaded your sample records because, of course, when I imported them into a shiny new 2.0 database these functions were invoked at import time so it changed the records to suit.
A SQL statement that would hit every record in authority. record_ entry to ensure that these functions get invoked would be "UPDATE authority. record_ entry SET active = active WHERE 1 = 1;". Maybe overkill, but better safe than sorry.
Also - clearly I should add some defensive coding to the authority interfaces to handle the case where the authority record does not have a 901 $c or 003!