>David-
>Aha! :-) I think we're on the trail of it now! You do not want to set a relation to a table that will be the rowsource of a combo. Binding the cbo to a controlsource will handle that for you. That's one comment.

Yeah. I removed the relation, but guess what. Problem occured this morning in relationless version. Sigh!. I set a new trap and it caught the culprit red handed. (unfortunately I wasn't around to be able to use my magic powers to investigate state variables before the user walked all over the evidence).

However, completely clear out the old problem description. Here's new information on how it manifests itself.

The user enters a work order number in the primary combo (a dropdown list with interactive search enabled).

The record of interest does appear (as evidenced by the value of various fields ... all correct).

The user selects the "action" combo (it's the third cbo, based on an arraylist) and uses it to specify an action code that's paired with an action description.

Then the user uses the mouse to click in another textbox (just a vanilla text box sourced to a character field of wojrn).

And whammo! the textbox value changes (still very rare...usually this works fine). But in this textbox my trap lies. It compares the value of wojrn.wono to val(primarycbo.displayvalue) and gives the alarm when not equal.

What's actually happening is that sometime between the selection of the work order (using the primary cbo) and the eventual clicking on the textbox, the wojrn table pointer is being moved. It's not immediatly obvious because no refresh has accompanied the change...so textboxes update as they are selected.

The array based cbo is suspect.

But why is the problem so intermittent? The behavior is like some race condition( caused by background fetches to the server??) where the good guys almost always win.
>
>Also, if you are storing the OPINDEX code in the WOJRN, then don't also store the description. That's the charm and usefulness of normalized relational database. :)

Alas, succintness is not one of my virtues (had you noticed??). So, in trying to wade thru my verbiage, you may have overlooked my reason for keeping two copies of the description: the wojrn copy can evolve...the opindex copy is a default 'starter', if you will. I know, this trick has pitfalls. But it basically boils down to the choice of whether to hack or redesign when shoehorning old FP stuff into VFP....I'm sure we could wax philosophically on this subject for days.