Hi Evan,

I guess I wasn't completely clear in what I'm trying to do. There is only one database. Calling the form in 2 different ways lets the user:

1. Run what-if scenarios, not changing any stored data, when called from the menu. A dummy cursor, made with CREATE CURSOR, will be created in the menu procedure code prior to calling the form.

2. When called from the other ("primary") form, it will modify columns of the view underlying the primary form - that is, change actual working data in a database table.

That said, I'll still have a look at the Form.SetAll() method. I haven't used that before and I'm not familiar with what it can do. Thanks for the tip.

Regards. Al

>Hi Al.
>
>Some ideas...
>
>1) Have two copies of your entire system. One live and one test. No coding changes are required.
>
>-or-
>
>2) In the load event of the form determine whether your are in live or test mode (you probably pass a var or read a property to do this). Then set all the cursors to a live or test set of tables. This method only works for tables in a database, the code is similar for free tables. You might want to set AUTOOPENTABLES to .F. in the form dataenvironment. Here is an example:
>
>

>* load event of form
>* point to database depending on form "mode"
>IF thisform.AlDomanFormMode = "Test"
>   thisform.SetAll("Database","c:\alapps\testdata\testdb.dbc","Cursor")
>ELSE
>   thisform.SetAll("Database","c:\alapps\livedata\testdb.dbc","Cursor")
>ENDIF
>
>* open the tables again
>thisform.dataenvironment.opentables()
>
>

>
>>I have a form with some unusual requirements from a data standpoint. It can be called from 2 places:
>>
>>1. Directly from the menu. In this case, its controls will be based on a temporary cursor created before the form is called. Any changes to form controls will be discarded when the form exits. I call this "Training" mode.
>>
>>2. From another form. In this case, its controls will be based on a buffered view that underlies the calling form. When the form exits, any changed view columns will still be buffered in the calling form, ready to be saved or discarded by the user. This I call "Live" mode.
>>
>>Since this form is going to be moderately complex, I would *really* like to avoid making two separate forms. Is it possible to create a single form that could meet these requirements?
>>
>>I've played around a bit with DataSessionID, BufferMode and BufferModeOverride on a test form in Live mode. I can access the calling form's view and modify its values, but these changes seem to be "hot" (unbuffered) - the values in the underlying table have changed regardless of whether I save or revert in the calling form. I have little experience working with Data Sessions and Form/DE level buffering, so any pointers would be appreciated.
>>
>>TIA.