Network Connections

[matthewlowrance]

We have an application that uses an access database. Some of our
client have requested a Client /Server version that they can use over
their wan.

I have created a simple server that queries the database and then
turns the dataset into xml, then sends the xml across the network and
then the client turns the xml back into a dataset. This seemed like
the simplest method so the application could work client/server or
connect directly to the access database for other clients.

The only thing I'm unsure about is just generally what is the best
practice in a .net application, creating a single connection on the
client side and keeping it open for the duration of the application or
reconnecting to the server each time a new dataset would be requested
and dispose the connection objects/let them be garbage collected?

The server is multi threaded so it would work either way.

If there is a better architecture I'd would be happy to hear that as
well.

Thanks for any help,

Matt

 

[Cor Ligthert[MVP]]

Matt

Simple answer, you can use a webservice as it is about an Jet database (the
one used in the office access aplication I assume you are talking about).

Sending XML sets direct over internet is a little bit an old fashion way
like using FTP, not to forget the sercurity risk inherited in that method.

Database connections should be as short open as is possible. This is more
for the connectionpooling than for the garbage collector, that is not so
much dependend how long the connection is open.

Cor

 

[RobinS]

According to database guru Bill Vaughn, in such a case as this, it doesn't
hurt to open the connection and leave it open for the duration. You can do
some testing and try it out and see if you have a performance hit the other
way; my guess is that you will, just from my experience of using Access as a
backend.

Bill hangs out in the microsoft.public.dotnet.framework.adonet newsgroup. If
you try searching his posts you might find the one I'm thinking of. It was
fairly recent.

RobinS.
GoldMail.com