p2p.wrox.com Forums

Need to download code?

View our list of code downloads.


  Return to Index  

access thread: RE: Client Server vs file server


Message #1 by "Enzo" <enzaux@g...> on Sat, 1 Jun 2002 09:35:33 +0800
	Yup me too I think that Access is more on file server environment according to the books that I've
read.  Now what I'm asking is
what if I make a vb program then use Access backend.  I'll be using an ADO connection to access the database.  Now how would you
consider that?  still a file server setup or already a client server set up?

Thanks,

enzo

-----Original Message-----
From: PStreeter@C...
[mailto:PStreeter@C...]
Sent: Saturday, June 01, 2002 1:39 AM
To: Access
Subject: [access] RE: Client Server vs file server


Phillip Johnson wrote:

>Enzo, I think its very much a matter of opinion in this area whther this
>would be classed as a client/server application.

>I wouldnt really class it as such.

>I think that the definition of a client server application is that you
>have a client application that would send a request to the server
>application, which would then query the data source (ie the access
>database).  The client and and server application could both run on the
>same machine, but the point is that the server could be moved to another
>machine and, as long as the client knows its location, the system would
>still work.

>I would generally view Access as a data source and when talking about a
>Server application I would consider that to be an application that queries
>the data source and does some sort validating etc on the data.

>Hope this helps you, but like I said, this type of application would
>probably be up to some debate.

There is a very clear conventional definition here. A file server is what
we all know as a server on our LAN's. It looks to our workstations more
or less like one or more additional hard drives. The software on our
workstations asks for data almost the same way it would of its own
hard drive. The file server handles it as just sectors to be read or written
and has now knowledge of the nature of the data. MicroSoft Access uses
a file server this way. Through the .LDB files, however, Access in each of
our workstations communicates with Access in each other workstation to
keep track of who's got dibs on what data. To the best of my knowledge,
Personal Oracle is like this. However, Oracle and MS SQL server and a
number of other DBMS products are client servers. This is to say that the
Oracle server is software that runs on a computer also called a server and
is the only thing that works with the file system at the sector level. In this
environment Access is a client, and sends SQL to the Oracle server which
runs the query (in the hardware called the server) and sends the results
to the client. It also handles data locking. It is a more rugged environment,
and also costlier. (I used only the name Oracle to stand in for all such
software.)

I have been told that access can be installed in a file server. I don't
know if
it then acts like a client server, but my guess is no.

Paul






Message #2 by "Carnley, Dave" <dcarnley@a...> on Mon, 3 Jun 2002 09:23:49 -0500
In some sense it will be 2-tier client/server because you have a physical
separation between 2 machines that communicate to perform the tasks.  But it
is the most simple form of c/s because the server machine is doing little
more than organizing and retrieving data very passively (file system and MDB
architecture).

When most people use the term client/sever, I think they are referring to a
design with an active database server process on the server side machine(s).
Like SQL Server or Oracle.  It still organizes and retrieves data the way a
file system or MDB does, but it can also apply facts about that data to
generate different data, allowing more complex retrievals of the data it
stores.

So, I guess what I am trying to say is, there is not that much difference
between a file server setup and a client/server setup if you get down to the
basic principles.  A SQL process running on "the server" allows more
complexity to be handled on that layer but in essence the difference is only
a matter of degree.

you know, you could theoretically write an ActiveX EXE that resides on a
"file server" machine and it receives winsock messages from your client,
then according to that message it runs some access automation code (stored
queries etc) on a local (to it) MDB, and returns that data to the calling
program.  hey, you just wrote your own database server! :)




-----Original Message-----
From: Enzo [mailto:enzaux@g...]
Sent: Friday, May 31, 2002 8:36 PM
To: Access
Subject: [access] RE: Client Server vs file server


	Yup me too I think that Access is more on file server environment
according to the books that I've read.  Now what I'm asking is
what if I make a vb program then use Access backend.  I'll be using an ADO
connection to access the database.  Now how would you
consider that?  still a file server setup or already a client server set up?

Thanks,

enzo

-----Original Message-----
From: PStreeter@C...
[mailto:PStreeter@C...]
Sent: Saturday, June 01, 2002 1:39 AM
To: Access
Subject: [access] RE: Client Server vs file server


Phillip Johnson wrote:

>Enzo, I think its very much a matter of opinion in this area whther this
>would be classed as a client/server application.

>I wouldnt really class it as such.

>I think that the definition of a client server application is that you
>have a client application that would send a request to the server
>application, which would then query the data source (ie the access
>database).  The client and and server application could both run on the
>same machine, but the point is that the server could be moved to another
>machine and, as long as the client knows its location, the system would
>still work.

>I would generally view Access as a data source and when talking about a
>Server application I would consider that to be an application that queries
>the data source and does some sort validating etc on the data.

>Hope this helps you, but like I said, this type of application would
>probably be up to some debate.

There is a very clear conventional definition here. A file server is what
we all know as a server on our LAN's. It looks to our workstations more
or less like one or more additional hard drives. The software on our
workstations asks for data almost the same way it would of its own
hard drive. The file server handles it as just sectors to be read or written
and has now knowledge of the nature of the data. MicroSoft Access uses
a file server this way. Through the .LDB files, however, Access in each of
our workstations communicates with Access in each other workstation to
keep track of who's got dibs on what data. To the best of my knowledge,
Personal Oracle is like this. However, Oracle and MS SQL server and a
number of other DBMS products are client servers. This is to say that the
Oracle server is software that runs on a computer also called a server and
is the only thing that works with the file system at the sector level. In
this
environment Access is a client, and sends SQL to the Oracle server which
runs the query (in the hardware called the server) and sends the results
to the client. It also handles data locking. It is a more rugged
environment,
and also costlier. (I used only the name Oracle to stand in for all such
software.)

I have been told that access can be installed in a file server. I don't
know if
it then acts like a client server, but my guess is no.

Paul







Message #3 by "Randy Cornish" <rlcornish@c...> on Tue, 4 Jun 2002 00:34:23
I wouldn't get too hung up on the terminology that you use.  I've seen 
application architectures that were "pure" n-tier client server that were 
awful - poor performance, hard to maintain, not extensible, unstable.  
I've also seen straight Access 2-tier (GUI/data) apps that ran forever 
without problems.  It's possible to screw up anything.  Use the right 
architecture for the application's requirements AND considering the 
skills of whomever has to build it.

Better to have a warm, sturdy doghouse than a falling over high rise.  
Just make sure to do due diligence with your arch design. 

Having said all that, most (not all) multi-user apps are better suited 
when designed as n-tier.  Separate the Data Services from Business 
Services from User Services.  What physical machine they reside on is 
somewhat irrelevant to the tier design. 

R

> 	Yup me too I think that Access is more on file server environment 
according to the books that I've read.  Now what I'm asking is
what if I make a vb program then use Access backend.  I'll be using an 
ADO connection to access the database.  Now how would you
consider that?  still a file server setup or already a client server set 
up?

Thanks,

enzo

-----Original Message-----
From: PStreeter@C...
[mailto:PStreeter@C...]
Sent: Saturday, June 01, 2002 1:39 AM
To: Access
Subject: [access] RE: Client Server vs file server


Phillip Johnson wrote:

>Enzo, I think its very much a matter of opinion in this area whther this
>would be classed as a client/server application.

>I wouldnt really class it as such.

>I think that the definition of a client server application is that you
>have a client application that would send a request to the server
>application, which would then query the data source (ie the access
>database).  The client and and server application could both run on the
>same machine, but the point is that the server could be moved to another
>machine and, as long as the client knows its location, the system would
>still work.

>I would generally view Access as a data source and when talking about a
>Server application I would consider that to be an application that 
queries
>the data source and does some sort validating etc on the data.

>Hope this helps you, but like I said, this type of application would
>probably be up to some debate.

There is a very clear conventional definition here. A file server is what
we all know as a server on our LAN's. It looks to our workstations more
or less like one or more additional hard drives. The software on our
workstations asks for data almost the same way it would of its own
hard drive. The file server handles it as just sectors to be read or 
written
and has now knowledge of the nature of the data. MicroSoft Access uses
a file server this way. Through the .LDB files, however, Access in each of
our workstations communicates with Access in each other workstation to
keep track of who's got dibs on what data. To the best of my knowledge,
Personal Oracle is like this. However, Oracle and MS SQL server and a
number of other DBMS products are client servers. This is to say that the
Oracle server is software that runs on a computer also called a server and
is the only thing that works with the file system at the sector level. In 
this
environment Access is a client, and sends SQL to the Oracle server which
runs the query (in the hardware called the server) and sends the results
to the client. It also handles data locking. It is a more rugged 
environment,
and also costlier. (I used only the name Oracle to stand in for all such
software.)

I have been told that access can be installed in a file server. I don't
know if
it then acts like a client server, but my guess is no.

Paul





  Return to Index