Jojo,

Since you copied me I'll post back a couple of thoughts.

Network stability should be separately addressed and fixed.

If your object that manages the connection uses a wrapper method for SQLExec() then you can easily check the result and if it errors check the error and if the error indicates a connection failure problem it can SQLDisconnect() on the bad connection, reestablish a new connection and retry the SQL command.

Your approach is one way to do it, it has a performance drawback because establishing the connection can take quite a long time.

>This is pretty good and to all the suggestions here provided that your SQL Server or network connection is stable.
>
>There is a draw back with this approach.
>
>What if you stored your connection handle during your app startup and just close the handle on exit or on your forms load & destroy procedures but then your network connection link is broken or your SQL server just experience a problem and it goes down? This means that your connection handle is useless and not valid anymore.
>
>For me, I always connect and disconnect whenever inserting, updating, deleting and querying records, which means that I always create,connect & disconnect a connection handle.I prefer this and its a "GOOD & BEST PRACTICE".
>
>What do you think? Am I wrong with my BEST PRACTICE?