>>.txtRoute.Value = this.value
>>
>>That's where you changed a value in one of the tables. You may not think it merits a name of transaction, but nevertheless you've made your buffer dirty. And as soon as the record number in that table changes, with row buffering there's the automatic tableupdate. A transaction happening behind your back... makes you wish for aGremlinInfo(), eh?
>
>Hey, Dragan
>
>
>I can appreciate that the above line would change a value in the Route table - granted, but, as I said, there is no table buffering, either at the form or the table level. So how would a Tableupdate() be issued implicitly? Yes, aGremlinInfo() would be a useful tool :-)

Then it's updating the table as soon as it hits the next refresh or whatever - you may try this with a watch on that field in route (or whatever's the controlsource of .txtRoute), and since it's a primary key - you get what you get. I really don't know the event firing sequence here, but since txtRoute is a bound control, at some point its controlsource must have been getting updated, and that's when the RI kicked in. With no buffering it should happen as soon as this update happens; with buffering it would happen on tableupdate().

IOW, RI is triggered when you write to a table. Since you had a programmatic change to the value of a (primary key-) bound textbox, it would be interesting to find out the event firing sequence, until we find the point where the textbox wrote its value into its controlsource.