Microsoft access is a mere file or data-base server

Question

A database-server serves all requests, weather coming from local-host or remote client and to listen any request, a database server must run on a port to listen requests on that port.

As far as i know, Microsoft access don't run on any port, and it is not possible to request Microsoft access on remote machine using

DriverManager.getConnection("URL", "user", "password");

but possible if your data-source is MySql, Oracle, etc... using,

DriverManager.getConnection("jdbc:mysql://ipAddress:portNo./schemaName", "user", "password");

(if i am wrong, please correct me).

Please u guys here help me with the concept, weather Microsoft access is a

a mere file for storing data (because it don't runs on any port),

or a database server (because for Microsoft-access Type-1 driver is available , it means it must be a data-source because drivers are only available for data sources).

Answer 1

AFAIK, MS Access is a database and you can connect to it through ODBC etc, but it is not a database server in the way SQLServer, MySQL, Postgres or Oracle are database servers.

Answer 2

Access is a file that can be attached to via the JET engine or many others. But it is a file. This means that if too many people attempt to connect to it there have been stories of it becoming corrupt and the whole db lost! It is not anywhere near as powerful as the other database engines you mentioned.

Answer 3

Microsoft Access databases can be used over ODBC or using a shared file system, so from that standpoint they can be considered multiuser databases.

This not really a database server from the standpoint that, there is not one location that serves queries up to clients. Unless you are using ODBC, each "client" has it's own copy of the database engine.

Access is not designed for many users, and does not have many of the properties that you normally think of when talking about database servers. Including scalability and robustness.

Answer 4

Access does not provide networked connectivity beyond a file share. There is no "Access" port.

Answer 5

It does not run on a port. It's just a file.

Answer 6

MS Access is a file-based database system but technically speaking, so are many other database systems. SQL Server, for example, will store it's data in a single file and can behave in a way that's very similar to Access. Then again, SQL Server has much more additional features.

But is Access a database server? Well, that depends on your definition of what a server should do. It is possible to create an Access database and give it some server-like functionality by writing some code to "serve" your data to some client application. Been there, done that. And actually, Access has been popular in the past for several cheap-hosted websites as database to e.g. run a forum or guestbook on.

To make things more interesting, Access databases can be accessed through COM. And COM objects can be created on a remote system. So theoretically, through ADO you can already access an Access database on another machine.

Access is also reasonably able to handle multiple users and offers some basic security, if need be.

MS Access is also more than just a database file format, although most people tend to forget this. MS Access is part of MS Office and as such it provides much more functionality than just a file-based database system. (Then again, even Paradox is more than just a file-based database if you buy the complete product from Corel instead of just using the database files plus drivers.)

Btw, the term "server" can be confusing. You don't need to run something on a port to make it a server. Basically, a database server is just some program that provides database services to other programs and computers. With Access, you can technically do both, so yes: Access is a database server. (Albeit a very primitive one.)

Answer 7

Access is not a database to begin with.

It is an application development environment that ships with a default database engine, Jet (or ACE in A2007, which is just an updated version of Jet), and that uses Jet MDBs or ACE ACCDBs for storing its application objects.

Your question is not about Access. It is about the Jet database engine.

Jet is not a server database. There is no process running on the server through which all communication with the Jet data store is managed.

Instead, Jet is a file-based database system. Each user runs Jet locally in memory, and opens the database file in shared mode. Locking of the database file is managed via the LDB file.

ODBC does not provide server functionality to Jet data. It is simply another user of a file.

Answer 8

If you put the file on a windows file share, then protocol is SMB, the port is 445. The machine with the file is called a File Server, so in a sense, it is a server app, but MS-Access isn't the server, the SMB bits are. What SMB doesn't do that a real sql server would do is manage the concurrent access.

Answer 9

In determining whether something is a server or not, the issue of whether it has ports is a red herring. Ports are simply one means of interprocess communication. As others have already noted, other servers use named pipes or shared memory to communicate with clients.

The architectural feature that really makes a server is process isolation. This is true whether you are talking about web servers, database servers, or display servers like X Windows. In each case you have some important resource that you want to guard very carefully. Therefore you don't let anything but a few select processes touch it. If another process wants access to that resource, they don't get to work with it directly. They have to send the server process a message, "Hey server please perform operation X on Y and send me the results". The channel used for sending the message is relatively unimportant, the key point is that some independent process is charged with managing the resource. Contrast this with Access (or as somebody pointed out more correctly the Jet database engine). If your application uses an Access database, then your process open file handles on the database, performs the record locking, and does the index lookups. This is all conveniently hidden by many layers of library calls, and it probably involves many switches to kernel space, but in the end it is still your process that is getting all the CPU cycles and doing all the work. This is true even if you are accessing the Access database via ODBC, which is really just another layer of library calls.