Too much in front end?

[dalmond]

What started out as a simple dispatching log has now turned into a
complete Security Department Databse...sorta . I thank many many people
who shared their knowledge to help me accomplish what I've done.

Everything that is generated in our department, service calls,
reports, property inventory, etc is based off of a number generated
from the dispatch database. Because of that, I have been able to
incorporate different tasks, all in the same FE/BE setup but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

My question is this, would I be better off having multiple FE for each
seperate task? EG Dispatch logs, property logs, incident reports,
officer records, etc.?

Thanks again for your past and future help

Dave

[(PeteCresswell)]

Per da*****@verizon .net:

but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

My biggest front end was about 25 megs and there didn't seem tb any performance
problems associated with that size.... either that or the users were just numb
by then....

If the wait while it's copied down to the user's PC is a problem, you can add a
version number to the front end's name and enhance the batch file used for the
copy so that it checks to see if the latest-and-greatest version is already
there.

My intuition is that fragmenting the app into multiple front ends would prove
inconvenient/confusing for the users without speeding things up once it was
running.
--
PeteCresswell

[Rick Wannall]

I second what Pete says. Our front end MDE is about 40 MB, and we run it
FROM the network. No particular grinding performance problem. To my
surprise, although there is a clear difference when we run the app from a
local hard drive, it's not as enormous a difference as I expected, so we
left the live app onthe network and eliminate the distribution element.

Monitor the size of the MDE. They can bloat the same as an MDB. I have a
way to change the mode of my app from Live to Development etc, and then
relink all the tables automatically to the correct instance of SQL Server.
Every time I do that my little 40 MB MDE bloats up to about 250 MB. So, I
compact it down and everything's fine. But I can see it slowly bloating up
on the network as users get in and out. It's a slow bloat, so the next
version usually comes out and replaces the last one before there's a
problem, but in other arrangements size could be a problem. If your user's
copy stays on the local machine long enough, you could see that sort of
problem.

[Arno R]

Try to import everything into a new, fresh database.
It might help.

IMO 4 Mb is not 'that much' or 'too much' for a Frontend.
In fact that's not much at all ...

A few questions:
How many forms, query's, reports are we talking about?
How slow is "increasing ly slow"? Also slow with a few users?
What version of Access?

It's my guess that there are other issues here.

Arno R

<da*****@verizo n.net> schreef in bericht news:11******** **************@ u72g2000cwu.goo glegroups.com.. .

What started out as a simple dispatching log has now turned into a
complete Security Department Databse...sorta . I thank many many people
who shared their knowledge to help me accomplish what I've done.

Everything that is generated in our department, service calls,
reports, property inventory, etc is based off of a number generated
from the dispatch database. Because of that, I have been able to
incorporate different tasks, all in the same FE/BE setup but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

My question is this, would I be better off having multiple FE for each
seperate task? EG Dispatch logs, property logs, incident reports,
officer records, etc.?

Thanks again for your past and future help

Dave

[Larry Linson]

Two outstanding sources of information on performance in multiuser
Access-Jet systems are: (1) MVP Tony Toews' site at
http://www.granite.ab.ca/accsmstr.htm and (2) MVP Jeff Conrad's site at
http://home.bendbroadband.com/conrad...essjunkie.html.

I agree with the three very knowledgeable developers who responded to you...
the size, or content of your front end is NOT the problem. It is very common
to find that some not-overwhelming, and not-too-obvious design changes can
significantly improve Access performance.

Larry Linson
Microsoft Access MVP

<da*****@verizo n.net> wrote in message
news:11******** **************@ u72g2000cwu.goo glegroups.com.. .

What started out as a simple dispatching log has now turned into a
complete Security Department Databse...sorta . I thank many many people
who shared their knowledge to help me accomplish what I've done.

Everything that is generated in our department, service calls,
reports, property inventory, etc is based off of a number generated
from the dispatch database. Because of that, I have been able to
incorporate different tasks, all in the same FE/BE setup but the FE has
become increasingly slow and I am worried that I will see a problem
with data being corrupted or really anything negative. My FE is about
4mbs and is copied from the server location at each login. This is to
distribute the FE after any changes/updates.

My question is this, would I be better off having multiple FE for each
seperate task? EG Dispatch logs, property logs, incident reports,
officer records, etc.?

Thanks again for your past and future help

Dave

[dalmond]

>How many forms, query's, reports are we talking about?

How slow is "increasing ly slow"? Also slow with a few users?
What version of Access?

AccessXP

14 Forms, 31 query's, 5 reports, 3 modules, 52 tables(linked), 0 pages,
0 macros, 3 modules.

Slow to me is relative to how it responded when the database was 2
forms with very little coding and querying(sp?) being done. It is
used by 4(max) users at one time from different pc's and it is quite
usable, I am attempting to forcast as I can see this simple database
really expanding to include a Sql Backend when I learn that.

Thanks again!

Dave

[David W. Fenton]

"Rick Wannall" <wa*****@notado main.de> wrote in
news:Am******** ************@ne wssvr29.news.pr odigy.net:

Our front end MDE is about 40 MB, and we run it
FROM the network.

You have a separate MDE for each user stored on a file server? Why
in the world would you do such a thing?

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/

[w_a_n_n_a_l_l_ -]

Not sure where you got that idea. One only. Actually, one on the Texas
server and one on the Florida server, so users in each office are not
pulling the app itself from further than down the hall.

[Larry Linson]

<da*****@verizo n.net> wrote

How many forms, query's, reports are we talking about?
How slow is "increasing ly slow"? Also slow with a few users?
What version of Access?

AccessXP

14 Forms, 31 query's, 5 reports, 3 modules, 52 tables(linked), 0 pages,
0 macros, 3 modules.

Slow to me is relative to how it responded when the database was 2
forms with very little coding and querying(sp?) being done. It is
used by 4(max) users at one time from different pc's and it is quite
usable, I am attempting to forcast as I can see this simple database
really expanding to include a Sql Backend when I learn that.

Access 2002, the Access component of Office XP, is, in my experience, a
solid, stable database with very little less in the way of features/function
than Access 2003.

That is not an extraordinary number of objects. At one time I worked on a
corporate real estate database (Access client - Informix server) that had a
total of approximately 1000 total objects in the Access 2.0 client DB. The
only performance bottleneck we experienced was the communications network,
and some really "examples of what not to do" code left by previous developer
(it was easier to re-implement most of those than to try to patch them.

A well-designed, well-implemented standalone, single user database just
split does not necessarily make a well-designed, well-implemented multiuser
database; a a well-designed, well-implemented multiuser database, just
upsized, does not necessarily make a well-designed, well-implemented
client-server database. In each case, you have to make some changes to take
best advantage of the environment.

If performance in the current is satisfactory, save your time and energy for
the conversion to Client-Server, when it comes. Or research C-S performance
and begin to use those techniques -- mostly, they will not hinder
performance in the multiuser environment.

Larry Linson
Microsoft Access MVP

[w_a_n_n_a_l_l_ -]

Status on our current Access 2003 MDE app:

329 Forms
47 Modules (about one third of them of them class modules)
891 Queries
80 Reports
64 Tables (local)
188 Tables (SQL Server)
About 60 K lines of VBA code

In production we see acceptable performance and rarely experience any
problem not caused by some oversight of yours truly.

I don't see why 14 forms et al would be the cause of any great problems.