Re: Tips on domain aggregate replacements

Thanks, Tom. I have implemented much of this in my current/ongoing
development, but you know how it is with old apps sometimes. The
methodologies I used three years ago are very different from the way I
develop today, and it is painful to watch some of the old apps in action
without the time to go through them & update some of the efficiency issues
(too many new projects to do...)

"Tom Wickerath" wrote:

Hi Brian,

Not sure if you are still following this thread, but this caught my attention:

Several of my other FE/BE db's seem to suffer from network latency issues,
and I have not had time yet to go through the process of keeping the
connection to the db open, ....

Please see the following article:

Implementing a Successful Multiuser Access/JET Application
http://www.access.qbuilt.com/html/multiuser_applications.html

Pay particular attention to:
1.) Disabling NameAutocorrect
2.) Setting all subdatasheets to [None] and
3.) Establishing a permanent connection for each user (very easy to do).

In addition, this article includes lots of useful tips such as using indexes
to help prevent table scans, and using an unbound search form to help locate
records that the user may want to edit.

If you can remove a page count in reports (Page X of Y), your reports should
open much faster too.


Tom Wickerath, Microsoft Access MVP

http://www.access.qbuilt.com/html/expert_contributors.html
http://www.access.qbuilt.com/html/search.html
__________________________________________

"Brian" wrote:

I will try moving the DSum's to the report. I already have several others
there, and the quirk is that it seems to make navigating from page to page
rather slow (of course, there could be some other reason for that).

This already is a split db, but the users are 400 miles away from the server
hosting the data:) They are all running the same copy of the FE locally on a
single terminal server via TS/RDP sessions. So, for all intents & purposes,
there already is a copy of executable on each user's station. The BE sits in
the same folder on that server where the FE sits. Would there be some
advantage to having them each run their own copies locally on the terminal
server?

It doesn't seem to have much impact on performance; the report takes just
about as long to run if they are all logged in as it does when I am logged on
testing it at night.

Having said all of this, I always split my databases. The only reason that I
don't have the BE sitting on a server in their office with a FE on each
workstation is that I have to get all my inefficiencies worked out first.
Several of my other FE/BE db's seem to suffer from network latency issues,
and I have not had time yet to go through the process of keeping the
connection to the db open, trimming out domain aggregate functions, etc. to
maximize efficiency.

I spend virtually all my time on user interface and data structure/integrity
issues - don't have much time to rethink methodologies...
.

Loading