>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
Précédent
Suivant
Répondre
Voir le fil de ce thread
Voir le fil de ce thread à partir de ce message seulement
Voir tous les messages de ce thread
Voir tous les messages de ce thread à partir de ce message seulement