>I have a billing file that contains trips and their cost. I also have a history file that has trips and their cost. They have a common key of tinstkey. If the user modifies the cost in the billing file, I go seek that record in the history file and modify it. Same if they delete or add a trip to the billing file. I don't do the reverse.
>

Yep.. update trigger first every time you update a record. Your trigger could call your code... this way it becomes independent on the code that modified the billing record.

>In most places I use an integer for the pk so the user never changes it. In some places, though, where the users are used to calling a thing by it's code, I just used the code as the key. Usually the code won't change, but since it is possible for the user to change it, I need to make the update in all tables that use this code. I plan to write a program to search all the tables and change it.
>

This is called Cascading the change... not only is the trigger the best place for this, but this is supported by the Referential Integrity builder...

Create a persistent relationship between the tables, then right click on the relation (line between tables) and choose Referential Integrity.

>Thanks,

Sure.

>
>-Michelle

BOb