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 "increasingly slow"? Also slow with a few users?
What version of Access?

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

Arno R

<da*****@verizon.net> schreef in bericht news:11**********************@u72g2000cwu.googlegr oups.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*****@verizon.net> wrote in message
news:11**********************@u72g2000cwu.googlegr oups.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 "increasingly 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*****@notadomain.de> wrote in
news:Am********************@newssvr29.news.prodigy .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*****@verizon.net> wrote

How many forms, query's, reports are we talking about?
How slow is "increasingly 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.

[dalmond]

That's comforting. I've read that saved queries are faster than coded
queries so I've attempted to go that route as much as possible. I've
also gleened most MVP sites and posts for efficacy tips and techniques.
Thanks all for your attention to this.

Dave
w_a_n_n_a_l_l_-@-_s_b_c_g_l_o_b_a_l._n_e_t wrote:

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.

[Larry Linson]

<da*****@verizon.net> wrote

That's comforting. I've read that saved
queries are faster than coded queries so
I've attempted to go that route as much
as possible. I've also gleened most MVP
sites and posts for efficacy tips and techniques.
Thanks all for your attention to this.

I've read and heard that same advice, but to be honest, I have never seen a
case where you could determine the difference between the two at the user's
workstation. CAVEAT: I have not tried this comparison with massive amounts
of data.

Larry Linson
Microsoft Access MVP

[David W. Fenton]

w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t wrote in
news:9l*******************@newssvr12.news.prodigy. com:

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.

Then you're DOING IT WRONG. Sharing a front end is just stupid.
Period.

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

[David W. Fenton]

da*****@verizon.net wrote in
news:11**********************@f6g2000cwb.googlegro ups.com:

I've read that saved queries are faster than coded
queries so I've attempted to go that route as much as possible.

The difference is going to be completely negligible in the vast
number of situations. What you get with a saved query is a
precompiled query plan that is optimized by Jet to be as efficient
as possible. If you don't have a saved query the optimization is
done each time you run the SQL.

I used to litter my apps with lots of saved queries for precisely
the reason you give, but managing them became too hard, and now I
save a query only when it has an advantage other than supposed
performance increases.

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

[(PeteCresswell)]

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

Slow to me is relative to how it responded when the databas

This probably isn't going to help, but is worth doing as SOP anyhow: Open up
each table in Design mode, right click anywhere, select 'Properties', and change
'SubDatasheet Name' from '[Auto]' to '[None]' - unless, of course you are
using that feature.

I've seen it speed up the opening of some tables significantly.
--
PeteCresswell

[w_a_n_n_a_l_l_ -]

Now we're rehashing old topics. You indicated previously that you have had
great problems with this. I have not.

I was correcting your mistake in thinking that I said I was keeping a copy
of the front end on the network file server for each user, nothing more.

[Arno R]

"(PeteCresswell)" <[e-mail]> schreef in bericht news:6h********************************@4ax.com...

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

Slow to me is relative to how it responded when the databas

This probably isn't going to help, but is worth doing as SOP anyhow: Open up
each table in Design mode, right click anywhere, select 'Properties', and change
'SubDatasheet Name' from '[Auto]' to '[None]' - unless, of course you are
using that feature.

I've seen it speed up the opening of some tables significantly.
--
PeteCresswell

Good idea, but I would not do this manually for each table ...
Look here: http://support.microsoft.com/?kbid=261000
There is code to TurnOffSubDataSheets() on that page.

Arno R

[David W. Fenton]

w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t wrote in
news:xz********************@newssvr29.news.prodigy .net:

Now we're rehashing old topics. You indicated previously that you
have had great problems with this. I have not.
Well, perhaps some of the problems you are having would go away if
you'd distribute your apps properly.
I was correcting your mistake in thinking that I said I was
keeping a copy of the front end on the network file server for
each user, nothing more.

I knew perfectly well that you were doing it wrong when I asked the
question. I was trying to remind you of your error.

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

[w_a_n_n_a_l_l_ -]

I am not reporting any problems at this time. Could you have me confused
with another poster?

[David W. Fenton]

w_a_n_n_a_l_l_ -@-_s_b_c_g_l_o_b_a_l._n_e_t wrote in
news:e8*********************@newssvr29.news.prodig y.net:

I am not reporting any problems at this time. Could you have me
confused with another poster?

Were you not commenting on the problem with the front end being
slow? Perhaps that's because it's being shared, which means it has
to be loaded across the network and that there is contention for the
objects being loaded by multiple users simultaneously.

And if you're sharing front ends, you *do* have a problem, whether
you choose to recognize it or not.

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

[w_a_n_n_a_l_l_ -]

No huge problem with slowness. I mentioned in passing, replying to the OP,
that we had tested performance running a copy from the network and a copy on
the workstation. The difference was not sufficient to motivate us to
distribute beyond the network server. We did put one each on the Texas and
Florida servers, but not one for each user. Maybe that's the part you
misread.

If we experience a problem related to sharing the front end we'll
reconfigure our distribution.