Thanks, Godfrey.

Thats basically how I've come to understand the MM model.

In this particular case, I wanted to use a grid to select the foreign key instead of a combo box, allowing the user to choose different sort orders via the various columns, and have the grid on a seperate form that is called from a button. This view was read only, so I didn't see a need for a BO for it, thus was surprised when I dropped it on the basemodalform and it wanted the SetFilePos method. MM seems to be assuming here that anything you throw in a grid will be the primary DAO of a bizobj, as opposed to using a view that is an alternate DAO.

Thus my question as to whether I was understanding the model properly.

I still think it's a bug, which can be solved easily by checking if the SetFilePos method exists before calling it.

June


>June:
>
>Let's assume you can talk about a "typical form".
>
>My understanding of the MM model is this.
>
>A typical form, if it is going to allow data to be entered and edited, will have a view behind it that in turn will allow access to one or more tables. The form will have a BO to control its data and the above view will be entered as the first DAO in the BO. This will be the Primary BO. This is the only DAO that will allow data to be written to its underlying table.
>
>In addition, that same simple form may have a combobox that requires a (read only) list view to allow a foreign key to be selected and entered into the main view (in the previous paragraph). This view will also be included in the same BO. There might be more than one of these RO views in the BO that support the primary DAO. None of thesee will be the first DAO in the BO.
>
>This one BO will be sufficient to bind all controls on all pages of this form to the underlying view. The BizObjMaintenanceForm object model has a form pop up for data input. Input is to the same view. It therefore uses the same underlying BO.
>
>If you have a multipage form that is controlling more that one set of tables you will need a second (or third) BO on later pages of the form. This will need to be switched to become the Primary BO when you click on its page(s).
>
>I guess the common thread here, as I see it, is that each updatable view needs its own BO that is, or is set to be, the primary BO. The first view in each BO is the only one that can be updated.
>
>If someone else has said this better, ignore this post.
>
>Godfrey