>>
>>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.

Thanks but this is all academic now. As I said, I've taken the binding from the text box; it should never have been on Route.Route anyway, as I merely use this field to display the Route ID after the desired route has been selected from a combo, whose source is a cursor of reduced fields from the Route table anyway.