On Fri, Oct 17, 2008 at 8:30 AM, Grant Johnson <[EMAIL PROTECTED]> wrote: > Thanks Mike. > > That's easy then. > Bear with me... > > What happens to rows in other tables? > - The "label" field will match in asset.call_number is the call number > - asset.copy contains the barcode
Actually, asset.call_number and asset.copy will stop the delete (foreign keys). They are both similarly protected from deletes, so it would be best to update the record field on asset.call_number, setting it to -1 instead of the records you're attempting to delete. > - metabib.full has marc field info. (Is this index that will get rebuilt?) This table, and others like it, will get a cascading delete. --miker > -- > > F. Grant Johnson > Systems Coordinator > Robertson Library > University of Prince Edward Island > >>>> On 2008/10/16 at 9:04 PM, in message > <[EMAIL PROTECTED]>, "Mike Rylander" > <[EMAIL PROTECTED]> wrote: >> On Thu, Oct 16, 2008 at 2:27 PM, Grant Johnson <[EMAIL PROTECTED]> wrote: >>> I take it that it is not as easy as deleting rows from the >> biblio.record_entry table!?! >> >> It is that easy. However, to /really/ delete them you'll need to drop >> (and later reapply) the rule protecting against true deletes on that >> table: >> >> BEGIN; >> DROP RULE protect_bib_rec_delete ON biblio.record_entry; >> -- >> -- ... delete some records ... >> -- >> CREATE RULE protect_bib_rec_delete AS ON DELETE TO biblio.record_entry >> DO INSTEAD UPDATE biblio.record_entry SET deleted = TRUE WHERE OLD.id >> = biblio. >> record_entry.id; >> COMMIT; > > -- Mike Rylander | VP, Research and Design | Equinox Software, Inc. / The Evergreen Experts | phone: 1-877-OPEN-ILS (673-6457) | email: [EMAIL PROTECTED] | web: http://www.esilibrary.com
