The connection management shouldn't have any effect on this operation. That's more of an implementation detail.

But it depends what type of backend you're going against. If you're using SQL Server there's connection pooling and it's best to always open and close connections after each request even in WinForms applications (definitely in Web apps). There' little benefit to hanging on to a connection in terms of performance.

In WinForms your update mechanism will be determined by the databinding mechanism used. Typically you'll bind to a DataRow or entity object which acts as your local data store and the databinder will update when you tell it to commit the changes. This is an explict operation as it would have been in VFP if you didn't use VFP data <s>...

So if you need to update after each change you can hook your validation or lost focus events to force the update to the database through the databinder. This is not terribly efficient, but it can be done by hooking up the events. What you'll want to do is create a single event handler on the form that is called by all the 'submit' fields (or all of 'em) so that you simply point at this handler from each control event.

+++ Rick ---


>I thought I posted this already, but I didn't get any responses and I couldn't find the original one so I am posting it again.
>
>This is really an overall connection design question. Winforms and physical network, not really a topology of disconnected users.
>
>In most cases in .net, I have seen apps (so far) written to be in a mostly disconnected state. In other words, entire forms are filled out completely and then the update to all fields done simultaneously in one sweep. Connections were only activated just prior to the data update and then the connection was closed. No connections were kept live.
>
>In VFP, we did this differently. We set up a connection for the user at app startup and then used that same connection throughout the life of the app. In some cases, updates were sent after all information on a form was filled out, but at other times it was necessary to update after each field was modified when immediate viewing of the changes was necessary to other users on the system.
>
>Ok, let's say that you have a form and as it is filled out, other users MUST see the data. In this case, will .net's means of handling connection pooling be sufficient for it to make sense to actually in each field create the connection, pass the data, close the connection? Or would it make more sense to keep a connection open for the life of the form? In this case the form is always open so the connection would always be open so perhaps a connection object for the life of the app makes sense?
>
>There is probably no future need for this specific app to run in a totally disconnected state. This app will always be physically connected to the server and data backend.
>
>Recommendations? If a connection is kept open for the life of the app (as we do it now in VFP) then just the enum could be passed for the fields to use for passing the updates. What would be the best way of accessing the connection object from a base control on a base form (in a baseclass scenario)?
>
>TIA