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