> Hey People,
>     I am trying to create a middle tier exe that can act as a communicator
> between my databsae adn my front end.  My software is going to be written
in
> VB.net with SQL Server 2000 as my backend.  This communicator will be a
> Gateway bew{*filter*} my front end and back end.  I am doing this because if I
> have my gui talk to my Sql 2000, I have a large load on the server (no
> matter how powerful it is).  I want to be able to take some of the stress
> off the server cpu usage.This app has constant streaming of data back and
> forth between the server and the client.it is somewhat of a thin client
> setup where some of the work is done at the client and some of it is dont
at
> the server.  Any ideas on how to start with this communicator

> Your architecture is going to cost you more with respect to resources, CPU
> usage and legacy code maintainence than what it is going to be worth.

> Don't you realize that you can talk to SQL server on its own port?

> > Hey People,
> >     I am trying to create a middle tier exe that can act as a
communicator
> > between my databsae adn my front end.  My software is going to be
written
> in
> > VB.net with SQL Server 2000 as my backend.  This communicator will be a
> > Gateway bew{*filter*} my front end and back end.  I am doing this because if I
> > have my gui talk to my Sql 2000, I have a large load on the server (no
> > matter how powerful it is).  I want to be able to take some of the
stress
> > off the server cpu usage.This app has constant streaming of data back
and
> > forth between the server and the client.it is somewhat of a thin client
> > setup where some of the work is done at the client and some of it is
dont
> at
> > the server.  Any ideas on how to start with this communicator

> I understand that, liek I said, the way the software was written,
> previously(and I am not going to change that not enough time) I need a
> middle communicator because the constant hitting of the SQL server form
> 50-100 clients tends to bring a major load on the server.  This app
> communicates to soem hardware. THis hardware returns information to the
> communicator and too the gui on teh Server, then this informaiton has to
be
> broadcasted out to from 5-100 clients.  And most of the time it is a
> constant thing.


> > Your architecture is going to cost you more with respect to resources,
CPU
> > usage and legacy code maintainence than what it is going to be worth.

> > Don't you realize that you can talk to SQL server on its own port?

> > > Hey People,
> > >     I am trying to create a middle tier exe that can act as a
> communicator
> > > between my databsae adn my front end.  My software is going to be
> written
> > in
> > > VB.net with SQL Server 2000 as my backend.  This communicator will be
a
> > > Gateway bew{*filter*} my front end and back end.  I am doing this because if
I
> > > have my gui talk to my Sql 2000, I have a large load on the server (no
> > > matter how powerful it is).  I want to be able to take some of the
> stress
> > > off the server cpu usage.This app has constant streaming of data back
> and
> > > forth between the server and the client.it is somewhat of a thin
client
> > > setup where some of the work is done at the client and some of it is
> dont
> > at
> > > the server.  Any ideas on how to start with this communicator

> Well, what do you have so far?

> Are you wanting code? Or just ideas?

> > I understand that, liek I said, the way the software was written,
> > previously(and I am not going to change that not enough time) I need a
> > middle communicator because the constant hitting of the SQL server form
> > 50-100 clients tends to bring a major load on the server.  This app
> > communicates to soem hardware. THis hardware returns information to the
> > communicator and too the gui on teh Server, then this informaiton has to
> be
> > broadcasted out to from 5-100 clients.  And most of the time it is a
> > constant thing.


> > > Your architecture is going to cost you more with respect to resources,
> CPU
> > > usage and legacy code maintainence than what it is going to be worth.

> > > Don't you realize that you can talk to SQL server on its own port?

> > > > Hey People,
> > > >     I am trying to create a middle tier exe that can act as a
> > communicator
> > > > between my databsae adn my front end.  My software is going to be
> > written
> > > in
> > > > VB.net with SQL Server 2000 as my backend.  This communicator will
be
> a
> > > > Gateway bew{*filter*} my front end and back end.  I am doing this because
if
> I
> > > > have my gui talk to my Sql 2000, I have a large load on the server
(no
> > > > matter how powerful it is).  I want to be able to take some of the
> > stress
> > > > off the server cpu usage.This app has constant streaming of data
back
> > and
> > > > forth between the server and the client.it is somewhat of a thin
> client
> > > > setup where some of the work is done at the client and some of it is
> > dont
> > > at
> > > > the server.  Any ideas on how to start with this communicator

> Ideas?  I dont code.


> > Well, what do you have so far?

> > Are you wanting code? Or just ideas?

> > > I understand that, liek I said, the way the software was written,
> > > previously(and I am not going to change that not enough time) I need a
> > > middle communicator because the constant hitting of the SQL server
form
> > > 50-100 clients tends to bring a major load on the server.  This app
> > > communicates to soem hardware. THis hardware returns information to
the
> > > communicator and too the gui on teh Server, then this informaiton has
to
> > be
> > > broadcasted out to from 5-100 clients.  And most of the time it is a
> > > constant thing.


> > > > Your architecture is going to cost you more with respect to
resources,
> > CPU
> > > > usage and legacy code maintainence than what it is going to be
worth.

> > > > Don't you realize that you can talk to SQL server on its own port?

> > > > > Hey People,
> > > > >     I am trying to create a middle tier exe that can act as a
> > > communicator
> > > > > between my databsae adn my front end.  My software is going to be
> > > written
> > > > in
> > > > > VB.net with SQL Server 2000 as my backend.  This communicator will
> be
> > a
> > > > > Gateway bew{*filter*} my front end and back end.  I am doing this
because
> if
> > I
> > > > > have my gui talk to my Sql 2000, I have a large load on the server
> (no
> > > > > matter how powerful it is).  I want to be able to take some of the
> > > stress
> > > > > off the server cpu usage.This app has constant streaming of data
> back
> > > and
> > > > > forth between the server and the client.it is somewhat of a thin
> > client
> > > > > setup where some of the work is done at the client and some of it
is
> > > dont
> > > > at
> > > > > the server.  Any ideas on how to start with this communicator

> You could create a TCP/IP client much like a chat client (example
available
> at

> N-US/101VBNETSamples.exe under "VB.NET - Advanced .NET Framework
> (Networking) - Use Sockets").  You could send the data from the device to
> the server piece and then broadcast it out to all of the clients.  During
> processing of your data, you could also save it to the database if that is
> needed.

> > Ideas?  I dont code.


> > > Well, what do you have so far?

> > > Are you wanting code? Or just ideas?

> > > > I understand that, liek I said, the way the software was written,
> > > > previously(and I am not going to change that not enough time) I need
a
> > > > middle communicator because the constant hitting of the SQL server
> form
> > > > 50-100 clients tends to bring a major load on the server.  This app
> > > > communicates to soem hardware. THis hardware returns information to
> the
> > > > communicator and too the gui on teh Server, then this informaiton
has
> to
> > > be
> > > > broadcasted out to from 5-100 clients.  And most of the time it is a
> > > > constant thing.


> > > > > Your architecture is going to cost you more with respect to
> resources,
> > > CPU
> > > > > usage and legacy code maintainence than what it is going to be
> worth.

> > > > > Don't you realize that you can talk to SQL server on its own port?

> > > > > > Hey People,
> > > > > >     I am trying to create a middle tier exe that can act as a
> > > > communicator
> > > > > > between my databsae adn my front end.  My software is going to
be
> > > > written
> > > > > in
> > > > > > VB.net with SQL Server 2000 as my backend.  This communicator
will
> > be
> > > a
> > > > > > Gateway bew{*filter*} my front end and back end.  I am doing this
> because
> > if
> > > I
> > > > > > have my gui talk to my Sql 2000, I have a large load on the
server
> > (no
> > > > > > matter how powerful it is).  I want to be able to take some of
the
> > > > stress
> > > > > > off the server cpu usage.This app has constant streaming of data
> > back
> > > > and
> > > > > > forth between the server and the client.it is somewhat of a thin
> > > client
> > > > > > setup where some of the work is done at the client and some of
it
> is
> > > > dont
> > > > > at
> > > > > > the server.  Any ideas on how to start with this communicator

> Hey People,
>     I am trying to create a middle tier exe that can act as a communicator
> between my databsae adn my front end.  My software is going to be written
in
> VB.net with SQL Server 2000 as my backend.  This communicator will be a
> Gateway bew{*filter*} my front end and back end.  I am doing this because if I
> have my gui talk to my Sql 2000, I have a large load on the server (no
> matter how powerful it is).  I want to be able to take some of the stress
> off the server cpu usage.This app has constant streaming of data back and
> forth between the server and the client.it is somewhat of a thin client
> setup where some of the work is done at the client and some of it is dont
at
> the server.  Any ideas on how to start with this communicator