>David-

>As for learning about relations...I learned about them so long ago, and not from Fox, that I don't really know how crystal clear the docs are from your pov. But, I think they are rather alright. Just takes practice, in my mind.
>

OK. I've reread the docs. (In this case, the description of the SET RELATION command)

Based on the example, I must be using the relation in a somewhat unconventional manner, although the way I'm using it seems to work and seems a rather reasonable way to use it.

In their example, they show the customer table as parent to the order table, where the customer table is in effect, a look up table that has all of the information associated with each customer number. By setting a one-to-many relationship from the customer table into the order table, bumping the customer table pointer automatically bumps the order pointer to the 'next' record having the customer code (assuming SET SKIP is on). That's nice, but I don't want to bump along by customer number (or in my case, opcode).

I'm set up so that the look-up table (opindex) is the child of the work-order table so that as I bump along in the workorder table, by workorder number, the opcode of each workorder is automatically translated into it's corresponding 'operation description' which is specified in the opindex table. This seems like a perfectly reasonable thing to want to do, though in strict FP parlance it casts the table having the 'many' as the parent of the table having the 'one'.

If I interpret correctly, this is a 'many-to-one' relationship which is not even discussed in the official literature (at least I cannot find it with a string search).

In very general terms, I have tablea ordered by taga where each record has a field called code. Tableb, ordered by code, contains a character string corresponding to each code. I want to move the tablea pointer by bumping along in taga order, but each time I bump I want tablea.code automatically translated for display to the user. Seems like a very natural thing to do to me. But it casts the table having just the code field as the parent, and the table having all of the information related to code as the child. (Just the opposite of the example in the text, and counterintuitive, IMHO, from the use of the words 'parent' and 'child').

The upshot of all of this, is that since I'm using relations in what appears to be somewhat of an unconventional way, it could be the source of my problem. I think that at least in one case, the original problem was observed after the user had modified the cbo whose rowsource is involved in the relation we've been discussing.

I have to verify this.