This is a migrated thread and some comments may be shown as answers.

OpenAccess best practices

1 Answer 83 Views
Data Access Free Edition
This is a migrated thread and some comments may be shown as answers.
This question is locked. New answers and comments are not allowed.
Adrian
Top achievements
Rank 2
Adrian asked on 13 Sep 2012, 03:45 PM
All the OpenAccess documentation is well explained but for the windows forms application I have got the certain unclear questions.
I have an application that contains a form with one grid with 3 buttons : adding, change, delete.The problem is that when I press the add button I would like to open the transaction in the new open form in which I might have: client adding, product adding,etc.
I would like that my transaction should end by pressing the "Save" button from the adding form. I would like to find  a new method by the help of which I could keep the temporary data until the final saving process.It is better to know that by the help of the new form you can open new subsidiary forms in which you insert client form and also product form. I want my data should be kept until the pressing of the "Save" button.
I have found some methods using BindingSource object, BindingList<> but all of this should be transferred from 1 form into  another one as parameters.After adding the client in the context I can not read the data again for displaying it in forms without calling the "SaveChanges" method . I have tried to use the "FlushChanges" method but the moment it works in the concurrency mode it blocks one of the users. I'm waiting forward you professional suggestions.

1 Answer, 1 is accepted

Sort by
0
Viktor Zhivkov
Telerik team
answered on 18 Sep 2012, 02:52 PM
Hi,

Having several forms that can pop-up one from another indeed poses a development challenge.
You have to define which one acts as a transaction container and commit data only once when all other forms are closed.
Because newly created objects do not have a valid identity key you will have to pass them between dialogs/forms using constructor parameters or properties. Use constructor parameters to pass required "parent" object. When the associated object has weaker relation or is optional you can use properties to pass it. You can also define special methods that facilitate opening new dialogs using code like this (this is pseudocode!):
01.//this code can reside in MyParentClassEditDialog form class
02. 
03.public MyChildClass ShowMyChildClassEditDialog(MyParentClass parentInstance)
04.{
05.    var dialog = new MyChildClassEditDialog(parentInstance); //creates a new instance of the form
06.    if(dialog.ShowDialog() == DialogResult.OK) //checks if the dialog has been closed using OK button
07.    {
08.        // TODO: do any validation from parent side if necessary
09. 
10.        // sets the child object to the parent
11.        parentInstance.Child = dialog.ChildInstance;
12.    }
13.}
In this code snippet MyParentClass is a class that contains one or more related child objects. MyParentClassEditDialog class is the form used to edit/create new instance of MyParentClass.
MyChildClass is a related class. MyChildClassEditDialog is form that edits/creates new instances of MyChildClass type.

After you have build the whole object graph in memory (passing objects arround using constructor arguments and properties) in the Save button handler of MyParentClass all you have to do is call SaveChanges() method.
If you are adding multiple children to a parent instead of single one, make sure to set IsManaged flag (more info on the bottom of the page) for the target navigation properties in your conceptual data model. This will enable OpenAccess to track adding and deleting in collections and will make things easier for you.
Since all new your in-memory object will not have any valid identity keys you should use the navigation properties instead of the corresponding foreign key properties.

You do not need any explicit transactions because SaveChanges() method will wrap all SQL statements in a single transaction to ensure data integrity.
Calling FlushChanges() is not good idea if you plan to add Cancel button to your dialogs. The method call will push the data to the server and as you have seen can cause unpleasant side effects.

If you have any additional questions do not hesitate to contact us.

Regards,
Viktor Zhivkov
the Telerik team
Follow @OpenAccessORM Twitter channel to be the first one to get the latest updates on new releases, tips and tricks and sneak peeks at our product labs!
Tags
Data Access Free Edition
Asked by
Adrian
Top achievements
Rank 2
Answers by
Viktor Zhivkov
Telerik team
Share this question
or