Peter,

Whether or not any particular piece of code illustrates a problem or not doesn't really matter.

An interrupt handler must save/restore the state of any global item it changes during its execution.

If it does not then the rest of your code is subject to seemingly random failures. Think about this example with SET DELETED. If code normally runs with SET DELETED ON and there is an interrupt handler that turns it OFF and does not restore it to ON. This error won't be seen if there are no deleted records in the tables, but as soon as there are the code will begin giving different results after the first time the interrupt handler is triggered, and the error might not show up until thousands of lines of code after the errant handler was executed, making this sort of error very hard to track down.

>As I wrote elsewhere in this thread, my old understanding is that the next lines of code are not interrupted by any timer:
>

select [somefield] from [sometable] into array somearray
>t=_tally

>The test that Viv Phillips wrote (also in this thread) appears to affirm that understanding. You are suggesting that this understanding is wrong. Is that based on tests and/or experiences?