>>The fact that you have not yet experienced the problem with other connection types is no proof that you won't
>>But, more importantly, where will you close those connections ?
>
>That is a very important question and I have been wondering when someone would ask it.
>
>The framework exposes the dataset after a SQLExec() command or execute a SQLUpdate(), SQLDelete() or SQLInsert(). So, at least, for the first one, I cannot close the connection at the framework level. Because, correct me if I am wrong, but, if I close the connection, the DataSet will become out of scope. So, for now, there is no close. The next step, before seeing if I have to handle that, was to check the memory and see if this is really necessary or not.

Michel, a DataSet is not dependent on it's database connection. The DataSet doesn't need to know anything about where it's data comes from, unless you've specifically put code into your framework that somehow ties the two together. If so, this is not a good idea. Viv is correct about closing the connections. You should open, fill your DataSet, close & pass your DataSet around after that. Same with updating ... open, set up your update parameters, update, then close again.

And actually, you don't even need to specifically open your connection when filling a DataSet with DataAdapter.Fill() because the DataAdapter will automatically take care of the open/close for you. Open if it isn't already open & close it if it wasn't previously open.

~~Bonnie


>
>Based on your experience, what will happen on 12 new connections created during a hit for example. As they belong to the hit, they should go out of scope.
>
>As far as desktop applications, it doesn't create a problem either up until now. But, I would welcome any comment you may have to that issue.