Yes it is 2009/2/11 Dcam <[email protected]>
> > Fabio, > > Thanks for your reply. > > > So...What you are looking for is a way to maintain the session open and > the > > transaction alive for the whole winForm live ? > > No, only the session should be remaining open while the user edits/ > addd/deletes list items, not the (SQL) transaction. The idea is that > all these changes should not be written to the database until the user > presses the "OK" button to accept "his work". Otherwise he presses the > "Canel" button to discared "his work", which will close the session > and close the Form (IMO no rollback is needed because nothing was yet > ritten to the database). > > I read your posts you are refering to (forther down in this thread) > but I'm not realy sure if this is the solution to my problem. I think > I understand the term "Conversation-per-Business-Transaction" (CBT). > It's actually what I'm looking for. But there is one thing that I'm > not sure about: What if, while editing the data in the list (in my > example), I have to open a lookup window to select an ID or something > (eg. choosing a user (ID/name) to assign an issue in an issue tracking > system, or an issue ID to reffer to). The loopup window would have to > read the data from the database using a new CBT without "attaching" > them to the first and still running CBT, because these lookup entities > don't have to be traked for changes. Would this work with your > solution? > > > -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
