> Assuming the select statement for your grid looks something like

this:

>
> select
> pq.PART_ID,
> p.PART_NUMBER,
> pq.USER_ID,
> pq.QTY
> from PartsQuantity pq
> join Parts p
> on pq.PART_ID = p.PART_ID

Yes, thats coorect.

> then you can set the dataset's RequestLive property true and enter
> PartsQuantity into the KeyRelation property in order to make the

fields

> from the PartsQuantity table updateable.

I had the requestLive, but not the KeyRelation

> >Is using a IB_LookupCombo in the grid to display the part numbers

a

> >bad way to do this?
> >At the moment, the part table has around 2000 records,
>
> It's OK for 2000 records - but there is a better way, if you are

using the

> native IBO data access - please confirm.

Yes, using native IBO access.

> >but this will eventually be around 10,000 records.
>
> Not OK for 10,000 records. That also suggests that your PartsQty

table

> will be huge also and will require some serious restriction by

some WHERE

> criteria.

Yes, restricted by WHERE USER_ID = :uid
So only a particular user's parts are displayed at a time.

> >I am just wondering if this is a poor design because of the size

of

> >the part table,
>
> It's a poor design if you have no way to limit the selection of

parts, e.g.

> a part type or some other sort of grouping device so that you can

apply a

> WHERE criterion to get a smaller subset of Parts records.
>
> There is a lot more to be said about the techniques involved in

this sort

> of application task, including alternative ways to make joined

datasets

> updatable. More information about data structures and components

in use

> would help.

Understand.
I have applied the KeyRelation, and now I can edit the QTY field,
but not the PART_ID field. I am assuming that this is because I am
displaying the PART_NUMBER (through the join) and there is no way
IBO can go off and retrieve the PART_ID whenever a new PART_NUMBER
is entered.

Rgds,
-Ryan