global connections

[Mike P]

I am converting a VB6 app to C# and the VB6 app has 1 connection and 3
recordsets, all global and open all the time so that all the required
procedures can use them. Using C#, would it be best to have a global
connection and datareaders etc, or is it better to put all the db stuff
into a seperate class and make calls to this whenever I need to
read/amend data?

Any advice would be really appreciated.


Cheers,

Mike

 

[Nicholas Paldino [.NET/C# MVP]]

Mike,

Having a connection open all the time to a database is not a good thing.
If anything, you should be opening and closing it when you need it.

In general, it would be a good idea to abstract out the data access
stuff. This way, you create a single pipe through which all of your data
access will flow. This is a good thing, because any changes you have to
make will be propogated everywhere (instead of you having to go around and
change everything yourself).

Hope this helps.

 

[Guest]

I would think that for a client-server app (assuming that's what this VB6 app
is most likely), global connection actually make sense. since you can't
really take advantage of connection pooling in this situation, and opening
and closing physical connections all the time is too costly.

agree that data access stuff should still be abstracted out regardless.

Mike,

Having a connection open all the time to a database is not a good thing.
If anything, you should be opening and closing it when you need it.

In general, it would be a good idea to abstract out the data access
stuff. This way, you create a single pipe through which all of your data
access will flow. This is a good thing, because any changes you have to
make will be propogated everywhere (instead of you having to go around and
change everything yourself).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I am converting a VB6 app to C# and the VB6 app has 1 connection and 3
recordsets, all global and open all the time so that all the required
procedures can use them. Using C#, would it be best to have a global
connection and datareaders etc, or is it better to put all the db stuff
into a seperate class and make calls to this whenever I need to
read/amend data?

Any advice would be really appreciated.


Cheers,

Mike

 

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

Why can't you take advantage of connection pooling in this situation?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I would think that for a client-server app (assuming that's what this VB6
app
is most likely), global connection actually make sense. since you can't
really take advantage of connection pooling in this situation, and opening
and closing physical connections all the time is too costly.

agree that data access stuff should still be abstracted out regardless.

Mike,

Having a connection open all the time to a database is not a good
thing.
If anything, you should be opening and closing it when you need it.

In general, it would be a good idea to abstract out the data access
stuff. This way, you create a single pipe through which all of your data
access will flow. This is a good thing, because any changes you have to
make will be propogated everywhere (instead of you having to go around
and
change everything yourself).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I am converting a VB6 app to C# and the VB6 app has 1 connection and 3
recordsets, all global and open all the time so that all the required
procedures can use them. Using C#, would it be best to have a global
connection and datareaders etc, or is it better to put all the db stuff
into a seperate class and make calls to this whenever I need to
read/amend data?

Any advice would be really appreciated.


Cheers,

Mike

 

[Guest]

well, unlike a webapp that can service thousands of requests at a given point
in time, a client-server app usually will serve 1 user per machine. I don't
see how much you can gain by going to a connection pool over 1 constant
connection. unless I guess if you use a lot of threading to execute sql
commands concurrently. but that will put more stress on the DB server I
think since all the connections in the pool are kept open over a longer
duration.

Daniel,

Why can't you take advantage of connection pooling in this situation?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I would think that for a client-server app (assuming that's what this VB6
app
is most likely), global connection actually make sense. since you can't
really take advantage of connection pooling in this situation, and opening
and closing physical connections all the time is too costly.

agree that data access stuff should still be abstracted out regardless.

Mike,

Having a connection open all the time to a database is not a good
thing.
If anything, you should be opening and closing it when you need it.

In general, it would be a good idea to abstract out the data access
stuff. This way, you create a single pipe through which all of your data
access will flow. This is a good thing, because any changes you have to
make will be propogated everywhere (instead of you having to go around
and
change everything yourself).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I am converting a VB6 app to C# and the VB6 app has 1 connection and 3
recordsets, all global and open all the time so that all the required
procedures can use them. Using C#, would it be best to have a global
connection and datareaders etc, or is it better to put all the db stuff
into a seperate class and make calls to this whenever I need to
read/amend data?

Any advice would be really appreciated.


Cheers,

Mike

 

[Nicholas Paldino [.NET/C# MVP]]

Daniel,

I would say that it might be questionable whether or not to use
connection pooling then. If the stand alone app is going to perform many
data operations in a short period of time, or it does a lot of transactional
work in COM+, then I think it is warranted. But if it just does the
occasional query, then I wouldn't recommend it.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

well, unlike a webapp that can service thousands of requests at a given
point
in time, a client-server app usually will serve 1 user per machine. I
don't
see how much you can gain by going to a connection pool over 1 constant
connection. unless I guess if you use a lot of threading to execute sql
commands concurrently. but that will put more stress on the DB server I
think since all the connections in the pool are kept open over a longer
duration.

Daniel,

Why can't you take advantage of connection pooling in this situation?

--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I would think that for a client-server app (assuming that's what this
VB6
app
is most likely), global connection actually make sense. since you
can't
really take advantage of connection pooling in this situation, and
opening
and closing physical connections all the time is too costly.

agree that data access stuff should still be abstracted out regardless.

:

Mike,

Having a connection open all the time to a database is not a good
thing.
If anything, you should be opening and closing it when you need it.

In general, it would be a good idea to abstract out the data
access
stuff. This way, you create a single pipe through which all of your
data
access will flow. This is a good thing, because any changes you have
to
make will be propogated everywhere (instead of you having to go around
and
change everything yourself).

Hope this helps.


--
- Nicholas Paldino [.NET/C# MVP]
- (e-mail address removed)

I am converting a VB6 app to C# and the VB6 app has 1 connection and
3
recordsets, all global and open all the time so that all the
required
procedures can use them. Using C#, would it be best to have a
global
connection and datareaders etc, or is it better to put all the db
stuff
into a seperate class and make calls to this whenever I need to
read/amend data?

Any advice would be really appreciated.


Cheers,

Mike