>Dmitry,
>
>It is a good idea to make your own sqlconnection class
>
>In its init it accepts the connection string and stores it.
>
>You then call methods of that class - the same that exist now, but without the connection handle
>
>The class keeps its own connection handle, and if there's a connection failure on an sqlexec() or so, you can reconnect and repeat the sqlexec
>
>The class itself defines its behaviour, when to connect, when to disconnect, etc
>
>I think this may make life easier for you - well the sql part, this is

Gregory,

This is exactly what I am working on; a class to manage SQL Server connection. I do it a little different (minor really) than you describe. Instead of class receiving a string (connection string), the class loads the string from an XML file where the connection string parameters are stored. And I do have a method in this class called from the application getting the connection handle. Right now (as you could probably see from my exchange of messages with Sergey) I am trying to "simulate" cases where the connection to the server is broken or timed out. I want to have a strategy to handle it (no pun intended) gracefully.

Thank you.