We've used alternate indexes to do trigger type processing since 1990. In our case, we do it to handle two situations:
1. Track the records that have changed to handle secondary key updates for files where the secondary data isn't really in the file. We have a master person file for our police application. Rather than select the persons with a specific name and then look for the crime records for that person, we keep the person names in an attribute in the crime report records. Note, we did efficiency analysis on PI rev 7 to determine which made the most sense. I'm not sure if it would make as much sense now but it was significantly faster back then to handle it this way. 2. Track the records that have changed to handle updates of other databases. We have GIS applications that use other databases. These databases are updated at night from our main Universe system based on what records have changed during the day. My late co-worker, Rob Fisher, and I used stuff from several sources including Gyle Iverson and Lee Leitner to flesh out this idea. We even wrote our own paper on it way back in 1991. Georgia Pritchett City of Salinas > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Behalf Of Hona, David S > Sent: Monday, April 26, 2004 11:04 PM > To: 'U2 Users Discussion List' > Subject: RE: [UV] Problem reactivating select list[Scanned] > > > Triggers have more overhead associated with them: > - you have install the trigger in all your hashed files/tables > IIRC, you can't have triggers on non-hashed file types. > Regards, > David > -- u2-users mailing list [EMAIL PROTECTED] http://www.oliver.com/mailman/listinfo/u2-users
