By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,073 Members | 1,218 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,073 IT Pros & Developers. It's quick & easy.

A97: Might I need to set reference to Find and Replace 8.0?

P: n/a
MLH
Most of you will recognize that I'm talking about Rick Fisher's
product. I bought the version for Access 2.0 thirteen years ago
and fell in love with it immediately. Most of you know, by virtue
of my lame-ass posts that I only recently migrated from A2.0 to
A97 and only recently, I bought Rick's product to support the
newer platform.

Well, we've been on the topic of references lately and one that
I saw in the list was Find and Replace 8.0. I adore the add-in
in 97 as much as I did in 2.0 - but I have noticed that some of
my larger mdb's lock up during F&R just as soon as REPORTS
begin to be searched. I've thought it was a quirk in my machine.
So, I skip searching the reports. Or, if I need to, I shut down my
app AND MS Access, restart them both and THEN search the
reports by themselves. If it fails again, I reboot the machine. I
launch NO APPS other than A97 - utilizing as little memory as
possible and this generally does it. But if I start 1 damn little
thing - say, outlook express - I get the memory failure. Doing things
this way, I can generally make it all the way through. Otherwise,
Access tells me it has experienced an unrecoverable error and
has to shut down.

Might it be that I SHOULD have this reference checked? All
opinions welcome. Its worth mentioning that I have a gig of RAM
installed in this development box and I don't have any of it
allocated to a RAMDRIVE or anything like that.
Nov 13 '05 #1
Share this Question
Share on Google+
3 Replies


P: n/a
MLH <CR**@NorthState.net> wrote in
news:po********************************@4ax.com:
Might it be that I SHOULD have this reference checked?


Are you using the add-in programmatically, from VBA code? If not,
then there is no purpose served by having a reference to it.

Sounds to me like you have something corrupt in your reports
collection, or you the add-in has a bug.

Have you decompiled your database recently?

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #2

P: n/a
MLH
Might it be that I SHOULD have this reference checked?
Are you using the add-in programmatically, from VBA code? If not,
then there is no purpose served by having a reference to it.

No, I'm not. So that's not the problem.
Sounds to me like you have something corrupt in your reports
collection, or you the add-in has a bug. The anomoly occurs in all databases, once the number and size of
reports reaches some level. I can circumvent it by feeding say half
the reports to the search engine in one pass and the other half in
a second pass. That's been my work-around and has always done
the trick for me.
Have you decompiled your database recently?

That I have not. But the anomoly is consistent across all databases.
Brand new ones (IE, those with few or no reports) never present a
problem. I've never read another post expressing a similar problem.
Nov 13 '05 #3

P: n/a
MLH <CR**@NorthState.net> wrote in
news:g6********************************@4ax.com: [quoting me:]
Sounds to me like you have something corrupt in your reports
collection, or you the add-in has a bug.

The anomoly occurs in all databases, once the number and size of
reports reaches some level. I can circumvent it by feeding say
half the reports to the search engine in one pass and the other
half in a second pass. That's been my work-around and has always
done the trick for me.
Have you decompiled your database recently?

That I have not. But the anomoly is consistent across all
databases. Brand new ones (IE, those with few or no reports) never
present a problem. I've never read another post expressing a
similar problem.


I wonder if you have very complex SQL in those reports, because the
recordsource of the report has to be initialized for any
Search/Replace functionality to act on the report. I tend to
initialize complex report recordsources in the OnOpen events of the
reports, partly because I hate having to wait for the recordsource
to initialize in order to be able to work with the report.

Of course, it also makes some things about working with the report
in design view harder.

From what you've said, it sounds like the probelm is not your MDBs,
but the tool you're using.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc
Nov 13 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.