Slow editting?

[FP1]

Running Access 2003 with split front and back databases with the back on a
network server, when editting a report, over an hour's time the report
editor gets less and less responsive. It gets to point when I have click
on a control and wait five to ten seconds while Access does God knows what
with the network drive (the Windows network icon burns solid during that
wait). Sometimes quitting the database and reloading helps, but not always.

What's causing this? Why does Access need access a network drive when
resizing a control? How do I stop it from doing this? Thanks!

 

[Jerry Whittle]

Try turning off your virus checker for a little while for testing purposes.
If that improves things, there should be an option to exclude checking files.
Include .md* and .accdb to the exclude list.

If that doesn't help, Tony Toews has a list of possible fixes. Check out:
http://www.granite.ab.ca/access/performancefaq.htm

 

[John W. Vinson]

Running Access 2003 with split front and back databases with the back on a
network server, when editting a report, over an hour's time the report
editor gets less and less responsive. It gets to point when I have click
on a control and wait five to ten seconds while Access does God knows what
with the network drive (the Windows network icon burns solid during that
wait). Sometimes quitting the database and reloading helps, but not always.

What's causing this? Why does Access need access a network drive when
resizing a control? How do I stop it from doing this? Thanks!

Is the Report in the frontend (good) or in the backend (very NOT good!)? Just
editing the design of a report should not connect to the backend at all, much
less thrash it.

What specifically are you doing which generates this behavior? Editing the
data in the tables upon which the report is based, or altering the structure
and design of the report?

John W. Vinson [MVP]

 

[FP1]

Is the Report in the frontend (good) or in the backend (very NOT
good!)? Just editing the design of a report should not connect to the
backend at all, much less thrash it.

What specifically are you doing which generates this behavior? Editing
the data in the tables upon which the report is based, or altering the
structure and design of the report?

John W. Vinson [MVP]

The only thing I do different is that when I'm developing the report, I
often use a local copy of the database, so as not to take a chance
corrupting or altering production data. It runs fine when I do that. but
when running against production data, it does this network acess crawl.
Either when typing of resizing with the mouse. I can't see any reson why
it should need the network drive either. The report is on the front-end.

 

[FP1]

=?Utf-8?B?SmVycnkgV2hpdHRsZQ==?=

Try turning off your virus checker for a little while for testing
purposes. If that improves things, there should be an option to
exclude checking files. Include .md* and .accdb to the exclude list.

If that doesn't help, Tony Toews has a list of possible fixes. Check
out: http://www.granite.ab.ca/access/performancefaq.htm

Okay, thanks. I don't think it's the virus checker, but worth a try. I've
seen stranger things!

 

[John W. Vinson]

The only thing I do different is that when I'm developing the report, I
often use a local copy of the database, so as not to take a chance
corrupting or altering production data. It runs fine when I do that. but
when running against production data, it does this network acess crawl.
Either when typing of resizing with the mouse. I can't see any reson why
it should need the network drive either. The report is on the front-end.

Again:

Are you altering the *DESIGN* of the Access Report object - moving textboxes
around, changing labels, changing the Sorting and Grouping properties?

Or are you altering the *CONTENTS* of the tables upon which the report is
based?

They are two different things, with different sets of problems. You cannot
"edit" the data *in the report* - you're editing data in the Tables, and the
report is based on those Tables.


John W. Vinson [MVP]

 

[Tony Toews [MVP]]

The only thing I do different is that when I'm developing the report, I
often use a local copy of the database, so as not to take a chance
corrupting or altering production data. It runs fine when I do that. but
when running against production data, it does this network acess crawl.
Either when typing of resizing with the mouse. I can't see any reson why
it should need the network drive either. The report is on the front-end.

And you have the FE on your own system? You imply you do in your
first posting but you don't explicitly state that.

Access does need the field names and properties of the fields in the
query/report to which the report is bound.

However what makes no sense is getting slower and slower over time.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/