Also if the Select statements are lookup only, you might want to consider getting a dirty read by using the WITH (NOLOCK) or WITH (READUNCOMMITED) hints.

>Triggers should only be used sparingly and require a minimum of time to execute. I got this from an article I found on the Internet...
>
>Benefits and Uses of Triggers
>Now that declarative referential integrity (DRI) handles the brunt of
>referential integrity checking, these are the most common applications of triggers:
>
>. Complex defaults- A trigger can refer to the contents of other columns
> or other tables to determine the default contents of columns in a table.
> In these cases, you also may want to consider an approach that uses a stored procedure.
>
>. Complex column constraints-Advanced domain checking (including inter-row
> and multi-table lookups) is often best done in a trigger.
>
>. Nonstandard referential integrity-If your application calls for alternative
> actions in response to RI violations, occasionally permits users to override protections, or requires unusual RI checking, a trigger is often the most efficient method available.
>
>. Maintenance of dupicate and derived data- Updates to additional tables based on changes to one table can be distributed by using a trigger.
>
>When not to use Triggers
>
>Complex or poorly written triggers can create havoc in a system requiring
>good throughput and update performance:
>
>. Triggers hold open locks, prevent updates in place, and can create additional transaction log overhead.
>
>. Triggers should be avoided when an application program or stored procedure
> can perform the same work with minimal I/O overhead.
>
>. Triggers should never be used to handle simple data validation or simple DRI.
>
>. In any case, triggers must be written to run quickly and return as soon as
> possible.
>
>HTH
>
>>Hi,
>>
>>At some of my customers, i'm having problems with DEADLOCK problem.
>>We have a lot of triggers at some tables, with triggers a lot of SELECT and UPDATES.
>>
>>I'm working with VFP 7.0, and my code is like this:
>>
>>SQLEXEC(..., "BEGIN TRANSACTION")
>>
>>lFlag = .t.
>>SELECT myRemoteView1
>>IF !TABLEUPDATE(.t., .t.)
>> lFlag = .f.
>>ENDIF
>>IF lFLag
>> SELECT myRemoteView2
>> IF !TABLEUPDATE(.t., .t.)
>> lFlag = .f.
>> ENDIF
>>ENDIF
>>IF lFlag
>> SQLEXEC(..., "COMMIT TRANSACTION")
>>ELSE
>> SQLEXEC(..., "ROLLBACK TRANSACTION")
>>ENDIF
>>
>>
>>Imagine that Tables from myRemoteView1 and myRemoteView2 have triggers that invoke a lot of Updates and Selects to other tables.
>>
>>Since i invoked a transaction, what is SQL SERVER's work? Does he lock all the tables (or records?) existing in triggers?
>>
>>Should i eliminate those "heavy" triggers and send their Select and Updates as single instructions from my application?
>>
>>
>>Thanks in advance.
>>
>>
>>Ricardo Almeida