One more complication. In some cases, you might need to insert the New-Cust-Num so you can insert dependent records, then go back and delete the Old-Cust-Num. And if you have unique keys on other fields, you might have to delete the old dependent record before inserting the replacement depended record with the same alternate field key.
On Tue, Nov 20, 2012 at 6:36 PM, John Gilmore <jwgli...@gmail.com> wrote: > Mike A. Schwab writes: > > <begin extract> > . . . Just use the same program in case you need to change a legitimate > customer > number for some reason. I. E. two customers who keep using the same > number when they call in. > <end extract> > > In fact use that program twice. The only safe thing to do in these > circumstances is to give both of these customers new numbers. > > Duplicate customer numbers are not uncommon. Here there is no hint > that the problematic ones are part-number like, but of course they may > be. (Notoriously,. there are duplicate American SSNs, etc., and they > can give rise to duplicate composite account numbers. > > Because duplicate data are common the designs sketched out here should > be modified to include checks on the value of another datum that is > unlikely to be in error. > > An example. One on-line medical-history database known to me contains > 13 'John Walsh' patient records. So far DOBs disambiguate them, but > good design will make provision for using a varying number of tests if > and when they are needed for a particular ambiguous key value. [The > word 'particular' is important here. Piling more tests on all > transactions is a very bad idea, but it is a very common practice. > Richard Jones knows he has a problem, and he is likely to be patient > with questions about his DOB. Derek Tobias Parfit is likely to be > less so.] > > John Gilmore, Ashland, MA 01721 - USA > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
