<< Larry, the problem with triggers is performance. If you fire a trigger that logs every time someone accesses a record, you are generating an awful lot of traffic! >>
Yes and no. Yes, you would be running some code every time a record is "hit" for viewing. But the requirements of the HIPAA appear to be such that you are required to run that code by law -- my suggestion was for a way to get it to happen automatically rather than having to code it in every SELECT, PRINT, EDIT, BROWSE, etc function in the application. On the other hand, in a C/S situation (such as R:Tango or other web solutions) the code would only be running on the server, so there would be no network traffic overhead involved. << Despite the performance hit, the trigger will not work as designed. Any multi row form will not notify the database that row 1234 was accessed until the highlight in the form moves to that specific row of data. >> This would be an implementation decision when creating the feature. Typically record set operations in databases make a pass through the data to identify the records, then revisit each record when the "client" needs the actual data. In the case where a "window" of multiple records is being shown (such as a grid or multi-row region) all records are visited to show the data. Therefore, the feature could: 1) Fire for each row in the recordset as soon as the recordset is identified (big performance hit up front, and the trigger would fire for rows whose data was never requested). 2) Fire for each row in the recordset as it is visited for data (probably the "best" behavior). This would fire the trigger as each record was actually displayed (on the screen or printed) and would not fire for records that were selected but not displayed. 3) As an alternative, the trigger could fire ONLY ONCE for each recordset operation (ie for a SELECT or BROWSE statement), making available to the trigger code the table name(s) and where clause that caused the trigger to fire. The trigger programmer would be responsible for translating that information into whatever logging is required. -- Larry
