Re: Replication/Sychronization and security
- From: "David W. Fenton" <XXXusenet@xxxxxxxxxxxxxxxxxxx>
- Date: Fri, 25 May 2007 13:24:51 -0500
<Jan Kowalski <Tutaj wpisujesz ?wój nick>> wrote in
news:uaMj0gpnHHA.3952@xxxxxxxxxxxxxxxxxxxx:
I administrate three Access '03 DB's over a network. Performance
is slow
less because of the network and more because of how Access talks
to itself.
That is, because you've not engineered your Access application to be
efficient in retrieving information.
When the front end loads at the user's end and a query is run to
select data,
the user's instance sends a message to the networked backend.
No, it does no such thing. What happens when you run a query is that
Jet on your desktop requests from the *file server* the sectors of
the file on disk there that the back end's headers tell Access
include the indexes for the tables you're querying. Then Jet
processes the indexes locally on your computer and then sends a
request to the *file server* for the sectors of the file on disk
that include the data pages that store the records you need.
There is *no* processing on the server.
Access to an MDB on a file server is just like MS Word to a Word
document on a server -- nothing on the other end is doing anything
but reading off the disk and sending data, all of which is processed
on your local PC.
gathers the
data and returns the result. Well, sure this seems simple
enough, SQL does
the same thing.
A server database does not do the same thing at all. Instead, Access
hands off the request to a process running on the server, which then
processes the request in the server's RAM, filters the records to
just those needed to fulfill Access's request and sends back only
those records.
The processing that takes place in the server RAM with a server
database takes place in your workstation's RAM when you are using an
MDB back end (i.e., Jet).
The difference is that Access is kind of dumb at
searching
and it talks very slowly to itself. If your query involves any
modification
to the data...
No, Access/Jet is *not* dumb. It's extremely smart in knowing how to
request the minimal amount of data from the file server in order to
provide the result to your query. If you're experiencing slowdowns
in this process, then you need to re-engineer your query and perhaps
add appropriate indexes to your data tables. If there aren't indexes
on fields that are used for the basic criteria, then, yes, you're
likely to retrieve far, far more data with Jet than you would with a
server database. But that would be an indication of a *design* error
on the part of the person who designed the database schema and the
Access application, and not a problem with Access/Jet.
A SQL (or other enterprise level) backend will solve 93% of the
performance
issues. Access is really designed to be a small all in one
package for small
business and home users. It can be enterprise level as a front
end, but really needs a much more robust backend and coding.
There can be other problems with Access and a SQL backend, but
those are covered in other conversations.
Why did you post this? It's erroneous information to begin with, but
besides that, it's completely non-responsive to the question that it
purports to be a reply to.
--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/
.
- Prev by Date: Re: Limiting access to specific forms/queries.
- Next by Date: Re: Bypassing Startup
- Previous by thread: Re: Limiting access to specific forms/queries.
- Next by thread: Re: Bypassing Startup
- Index(es):
Relevant Pages
|
