|
Hi Folks, Can someone who's familiar with MARC imports and whatever else might rely on this index being unique give me some guidance on what functions would not work if that index were not unique--at least not unique during a major reload of cleaned up records into an Evergreen database? I know I've raised this issue before, but there've been a lot of changes in the code since then. I'm interested in two versions, at this point: 1.6 and 2.0 Can I change this index to eliminate the unique property and still have (most) things run without difficulty? As some for instances: Do the searches by TCN work properly if multiple hits occur in the database on a given TCN? Does import matching rely on this being unique? Other potential problems come to mind? We've got a situation where during the reloading of this data, there's going to be many collisions on TCN (because the TCN in biblio.record_entry is not consistent with the MARC data itself in many cases)--it'd simplify our life considerably if we could make it a non-unique index (at least for the several days' duration of the reloading). Thanks for any insights. John John M. Craig Alpha-G Consulting, LLC [email protected] www.alphagconsulting.com (801) 805-4963 |
