Design issue - OleDbConnection
-
Let's say we have a class A that wraps a DB table. Now suppose this has an Add method, should we use a OleDbConnection local to that function to do the insert? Or should we have a OleDbConnection member for the class A and open it in the constructor and kill it in the destructor. The Add function is an infrequently used function. A is a remotable object and my worry is that it might be kept alive too long and in such cases if there is a network outage or something, I am scared that the class will be destroyed out of the blue and the DB might not be closed properly. Any suggestions are welcome Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
-
Let's say we have a class A that wraps a DB table. Now suppose this has an Add method, should we use a OleDbConnection local to that function to do the insert? Or should we have a OleDbConnection member for the class A and open it in the constructor and kill it in the destructor. The Add function is an infrequently used function. A is a remotable object and my worry is that it might be kept alive too long and in such cases if there is a network outage or something, I am scared that the class will be destroyed out of the blue and the DB might not be closed properly. Any suggestions are welcome Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
You may be better off using a DataSet. It caches data from the server and you can store it on the client (Assume you connect to a data source and display everything in a data grid for example) Then you will perform any operations on the client and update everything in the end. Thus, you do not have to worry about the connection being help up. For additional info on datasets check my article here. I hope that helps. Best regards, Alexandru Savescu
-
You may be better off using a DataSet. It caches data from the server and you can store it on the client (Assume you connect to a data source and display everything in a data grid for example) Then you will perform any operations on the client and update everything in the end. Thus, you do not have to worry about the connection being help up. For additional info on datasets check my article here. I hope that helps. Best regards, Alexandru Savescu
Problem is that the DB connection is on the remoting server and it's the client that invokes calls remotely. The kind of app I have in mind had an issue that a client might connect and then disconnect only after 6 hours or even a full day. I am worried about a connection being alive for that long and timing out in between. Datasets also don't seem same for this. If a network failure occurs, then I won't be able to flush the data in time. Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
-
Problem is that the DB connection is on the remoting server and it's the client that invokes calls remotely. The kind of app I have in mind had an issue that a client might connect and then disconnect only after 6 hours or even a full day. I am worried about a connection being alive for that long and timing out in between. Datasets also don't seem same for this. If a network failure occurs, then I won't be able to flush the data in time. Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]
Well, having a connection open for 6 hours non-stop is bad in every sense you want: bad design, bad implementation etc. The Internet itself was not designed to keep connections alive (see the IP protocol). You have every reason for connections alive that long. You don't speak on a phone that much (and a phone keeps a connection open) Anyway, datasets may be a better option. You may from time to time flush data in backgound (say every 30 minutes). Also, if data is not flushed on time (or timeout occurs when updating) then you can catch an exception and always retry. Best regards, Alexandru Savescu
-
Well, having a connection open for 6 hours non-stop is bad in every sense you want: bad design, bad implementation etc. The Internet itself was not designed to keep connections alive (see the IP protocol). You have every reason for connections alive that long. You don't speak on a phone that much (and a phone keeps a connection open) Anyway, datasets may be a better option. You may from time to time flush data in backgound (say every 30 minutes). Also, if data is not flushed on time (or timeout occurs when updating) then you can catch an exception and always retry. Best regards, Alexandru Savescu
It's not about bad design here Alex. I don't have a choice here. A remote client may do what it wants to. We cannot dictate to it to close after a minimum while :-( I like your periodic flush idea. I'll do that. And yeah, I'll take a look at your Dataset article too :-) Thanks Nish
Author of the romantic comedy Summer Love and Some more Cricket [New Win] Review by Shog9 Click here for review[NW]