Hi Bob,

I appreciate you getting involved in this thread too. I have read the section in the manual you referred to many times and I understand about using transactions and I plan to use them, but maybe you are seeing something in that section that I am not seeing. Most of the problems I am having with the way I think the framework works is related to the user interface not the business object layer or the data access layer. The existing user interface seems to restrict me to editing one record at a time and then I am forced to either save the edits to that one record or discard them. Each time I attempt to navigate away from a changed record I am met with a "Save Changes?" dialog.

I want to be able to add any number of new records and/or delete any number of existing records and/or edit any number of existing records one at a time using standard textboxes etc. without being forced to save changes or abandon changes for each of those edited records. When I am finished editing all the records that I want to include in one transaction, I will click the Save button and I expect all my changes to then be persisted to the SQL database wrapped in a transaction. I want to use grids and/or navigationtoolstrips only for navigation purposes not for editing records.

Maybe I do not understand how child business objects interact with the user interface. I assume that after editing a child record I will be forced by the existing user interface to save changes or abandon changes before navigating to a different child record just like with parent business objects. If child business objects would allow me to edit multiple child records without being interrupted and then save them all at once, then I stand corrected, but I cannot find that information anywhere in the manual.

Sam

>What Sam (I believe) is referring to is a transaction situation where you would never save one record by itself as in the double entry method of accounting world dictates debits equal credits, therefore you would need at least two records saved or none. To facilitate this he would need a parent child relationship between two business objects via the framework and utilize database transactions.
>
>
>
>>Hi Bob,
>>
>>I am not following your comment. Sam was asking about editing records and navigating to another for edit without saving until all the desired records were edited. Although he could easily get rid of the "AskToSave" function, he wants to not save the DataSet until they are finished editing all of them. The framework does trigger a save or cancel when you navigate. Is there something in that section I am not seeing?
>>Tim
>>
>>>Tim,
>>>
>>>See the section "Establishing Business Object Relationships" in the MM.Net user guide.
>>>
>>>Bob
>>>
>>>>I am trying to understand the overall design of the Mere Mortals framework. After experimenting with the jump start, it seems that the framework expects the user to edit one record at a time and then save those changes before moving onto another record. If the user attempts to move to another record without saving the changes to the first record, they are asked if they want to save the changes. Answering No to that question seems to cancel the changes to the first record and then move onto the next record.
>>>>
>>>>I am a C.P.A. and in my world we work with a group of accounting transactions at a time. We may have several debits and several credits that need to be edited and saved together as a group. We may add new records or delete records or edit existing records but we want to save the entire group of records all at one time. I have experimented with the ImmediateDelete property of the Business Object to keep the framework from propagating deletions to the backend database immediately. But after deleting a record in the business object's datatable, I seem to be prohibited from doing anything with any other record until I either save the changes by answering Yes when prompted because I want to move to another record, or answering No which cancels the deletion.
>>>>
>>>>I must not be seeing the forest for the trees. Certainly there must be a way built into the framework to accomodate working with a group of records before saving all of them at one time. I never want to use grids for editing, I just want to be able to edit multiple records one at a time and then save all the changes.
>>>>
>>>>Sam Tenney