|
Home > Archive > MS Access Multiuser > April 2005 > Re: is access front end still pulling everything over the network?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Re: is access front end still pulling everything over the network?
|
|
| Larry Linson 2005-04-06, 8:05 pm |
| "djc" wrote
> thanks for the input. I had looked into
> this but its been a while. Just looking to
> confirm then that a db setup in the
> manor is still JET. So any inefficiencies
> that were there before the table move
> would still be there now (if not worse).
If you are looking for confirmation that Jet being involved is a problem,
then you are doomed to disappointment. Jet is not a problem -- in fact, it
turned out to be more capable and more efficient than even its developers
suspected it would. But, you are correct: if the orginal implementation
included inefficient uses of Jet, they will still be there. And, yes,
because of the following, moving from multiuser to client-server often does,
initially, perform worse.
And, just as a well-designed, well-implemented single-user database does not
automatically result in a well-designed, well-implemented multiuser
database, neither does a well-designed, well-implemented multiuser database
linked to a server automatically result in a well-designed, well-implemented
client application to the server database. You need to understand and take
advantage of the strengths of each of these environments.
It does not, as so many detractors claim "pull the entire database across
the network" -- that just is not so. It treats the shared folder just as it
would a folder on the local hard drive... retrieving only what it needs to
do whatever is the task at hand. If the database application is
well-designed and well-implemented that may be only the index on which the
record is selected, and the particular record (or "page", depending on what
you specified) of interest.
And, while you can get some gains from stored procedures, and other SQL
Server-specific items, I have worked on a number of client applications to
server databases where those were, by client demand, avoided. It turns out
that Jet-ODBC-server is far more efficient than many would suspect -- you
can get very good performance without resorting to stored procedures, etc..
(triggers are often used to implement referential integrity on some server
databases, and may be created by the data modeling software used by the
DBA). Microsoft SQL Server is something of an exception, because you can
specify referential integrity in a manner much the same as you do in Access.
The reason the client had us avoid using server-specific features was
two-fold: (1) they wanted to preserve their options to change server
databases, and, (2) competent Access developers were easier to find and less
expensive to contract than competent server database DBAs and developers.
Larry Linson
Microsoft Access MVP
| |
|
| thanks for the input Larry. What you have described is my understanding as
well. Unfortunately the developer working for us in not aware of how to
properly design a jet application. Or at least didn't do so.
"Larry Linson" <bouncer@localhost.not> wrote in message
news:eUkjvKwFFHA.1528@TK2MSFTNGP09.phx.gbl...
> "djc" wrote
>
>
> If you are looking for confirmation that Jet being involved is a problem,
> then you are doomed to disappointment. Jet is not a problem -- in fact, it
> turned out to be more capable and more efficient than even its developers
> suspected it would. But, you are correct: if the orginal implementation
> included inefficient uses of Jet, they will still be there. And, yes,
> because of the following, moving from multiuser to client-server often
does,
> initially, perform worse.
>
> And, just as a well-designed, well-implemented single-user database does
not
> automatically result in a well-designed, well-implemented multiuser
> database, neither does a well-designed, well-implemented multiuser
database
> linked to a server automatically result in a well-designed,
well- implemented
> client application to the server database. You need to understand and take
> advantage of the strengths of each of these environments.
>
> It does not, as so many detractors claim "pull the entire database across
> the network" -- that just is not so. It treats the shared folder just as
it
> would a folder on the local hard drive... retrieving only what it needs to
> do whatever is the task at hand. If the database application is
> well-designed and well-implemented that may be only the index on which the
> record is selected, and the particular record (or "page", depending on
what
> you specified) of interest.
>
> And, while you can get some gains from stored procedures, and other SQL
> Server-specific items, I have worked on a number of client applications to
> server databases where those were, by client demand, avoided. It turns out
> that Jet-ODBC-server is far more efficient than many would suspect -- you
> can get very good performance without resorting to stored procedures,
etc..
> (triggers are often used to implement referential integrity on some server
> databases, and may be created by the data modeling software used by the
> DBA). Microsoft SQL Server is something of an exception, because you can
> specify referential integrity in a manner much the same as you do in
Access.
> The reason the client had us avoid using server-specific features was
> two-fold: (1) they wanted to preserve their options to change server
> databases, and, (2) competent Access developers were easier to find and
less
> expensive to contract than competent server database DBAs and developers.
>
> Larry Linson
> Microsoft Access MVP
>
>
>
| |
| Larry Linson 2005-04-06, 8:06 pm |
| "djc" wrote
> thanks for the input Larry. What you have
> described is my understanding as well.
> Unfortunately the developer working for
> us in not aware of how to properly design
> a jet application. Or at least didn't do so.
There are a lot of less-than-optimum designs and implementations around, for
various reasons -- not always due to the developer's knowledge and
competence levels.
However, it may be time for you to find a developer with good experience in
the environment you want to target, and with good references, to come in and
review the database. Fixing a database can range from relatively simple
changes that do not require a great deal of effort; to something that just
should be redesigned and reimplemented, salvaging only the data from the
original.
Larry Linson
Microsoft Access MVP
| |
|
| thanks again Larry. Your input is always appreciated.
"Larry Linson" <bouncer@localhost.not> wrote in message
news:OcB7ILfKFHA.3512@TK2MSFTNGP15.phx.gbl...
> "djc" wrote
>
>
> There are a lot of less-than-optimum designs and implementations around,
for
> various reasons -- not always due to the developer's knowledge and
> competence levels.
>
> However, it may be time for you to find a developer with good experience
in
> the environment you want to target, and with good references, to come in
and
> review the database. Fixing a database can range from relatively simple
> changes that do not require a great deal of effort; to something that just
> should be redesigned and reimplemented, salvaging only the data from the
> original.
>
> Larry Linson
> Microsoft Access MVP
>
>
>
>
>
>
|
|
|
|
|