buda-base / drs-deposit

Harvard DRS Deposit base
1 stars 0 forks source link

Resolve inconsistencies in DRS records #87

Closed jimk-bdrc closed 3 years ago

jimk-bdrc commented 4 years ago

86 is caused by a SPROC returning no data set. The SPROC involved, GetReadyVolumes sees no Volumes which are not Queued That implies that all the batches we need to build are built. This is not the case - there are many volumes which have queued set, but have not been registered as built. So the implication is that they have not been set up to build.

jimk-bdrc commented 4 years ago
select label  from Volumes V
inner join Works W on W.workId = V.workId
left join Outlines O on V.volumeId = O.volumeId
left join PrintMasters PM on V.volumeId = PM.volumeId
where O.volumeId is null
and PM.volumeId is null
and W.HOLLIS is not null
and V.batchBuildId is null;

drs_VolumesNullBuild.csv.txt

jimk-bdrc commented 3 years ago

Created scripts to query BDRCCumulativeProdDeposits.csv and built batches to answer the following question: If I get a HUL DRS error saying an OSN was duplicate, what about all the other objects in the batch? Were they duplicates, too, in which case the whole build can get tossed out as already deposited, or, do I have to clear the DRS DB status of the other OSNs and have them built in a different batch.

I analyzed the existing builds and reset the flags on those duplicate builds. There weren't many (you can find out by querying Volumes for update_time > '2020-07-17')

Also updated Recovery.md to cleanup and reflect current technology.