Bob,

Thanks for taking the time to explain about MM for VFP. I think what you have described is precisely what I am looking for. Using your conceptual ideas, I think the biggest problem with MM .NET is trying to navigate in the grid (or by clicking navigation buttons). Presently navigating away from an edited record triggers the "Save Changes?" dialog with the only real choices being to update the backend database or to abandon the changes on the edited record. I think the DataSet and DataTable structure and the existing business objects behavior would work okay with only minor changes.

Now the challenge is to convince Kevin that this functionality is important enough that Oakleaf will make the changes for us.

Sam

>Sam,
>
>Unfortunately, I have not done what you want to do in MM.NET yet, however, I have done what you want in Mere Mortals for VFP. Since Oakleaf has developed both these products, I know that the concepts are built in. Right now, MM.NET does not have the extra user interface controls that made this relatively easy in MM for VFP.
>
>In the VFP version, I would have a maintenance form with multiple tabs. Since your an accountant, I will use a journal entry as an example. The first tab of the journal entry form would have the properties of the journal header table (or parent business object). On this properties tab would be text boxes for journal date, journal type, etc. with Save and Cancel buttons. The second tab would hold values from the journal details table (or line items) for the journal. But since there can be many details, it has to be contained in a grid (but we definitely do not want the grid control itself be updateable). The grid columns would be the columns contained in the journal detail (or child) business object such as debit/credit code, account number, amount, etc. Also on the tab would be three buttons (Add, Edit and Delete) that when clicked would bring up a modal form with text boxes for all the columns on the journal detail table or business object (The delete button would of course just delete the line item selected in the grid). The modal form would have an OK and Cancel button. Clicking OK on the modal form would add the journal detail to the table but it would be contained in the header transaction and still is subjected to the save or cancel from its parent header.
>
>When you have finished adding and editing line items, nothing has not been officially saved yet as you could click the Cancel button on the header tab and all your work would be cancelled. Or you could save all your work. Additionally, if you tried to close the form, the ask to save message is referring to the main business object and cancelling or saving through this achieves the same result.
>
>What I have explained above is conceptual. Now, how do you make this happen in MM.NET. Like I said above, MM for VFP had many different user interface controls that had built in containers for business objects, etc. and made this basically easy. But MM.NET does not have these. (If I am mistaken on this last statement, I would hope someone would chime in with a correction or maybe new user interface controls such as these will be released shortly by Oakleaf). So you will have to build them and have them incorporate the concepts listed in the section I mentioned ealier on parent/child relationships.
>
>
>
>HTH
>
>
>>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
>>