Windows 2000 upgrade breaks Access 200 app

  • Thread starter Thread starter Richard Grossman
  • Start date Start date
R

Richard Grossman

Access 2000 db located on fileserver (domain server)
Workstations with Windows 2000, all windowsupdates applied
Office 2000 on workstations, all officeupdates applied

This app has been working fine for years from
workstations with Windows 98.

Client bought and installed new workstations with Windows
2000.

Many many errors pop up in various places in the
application when run from Windows 2000. The Windows 98
workstations all are still working fine.

The users can access the database, but they get "object
invalid or not found" and "Expression too complex or not
found" errors. They can OKAY past them and continue
working, strangely enough.

I believe from about 10 hours of investigation that some
of the errors are caused by forms with subforms. After
showing a 3rd separate form (or grid) in front of them
(for example to select a client or order to display),
then when that other form closes, the new form is being
activated differently than before. I believe the subform
is being activated first whereas previously the main form
was being activated first.

This error is very very difficult to trace because if I
place a breakpoint before the error, the act of debugging
and bringing up the debugger window prior to hitting F5
to continue prevents the error from occurring.

I have fixed one form by deactivating the subform prior
to bringing up the 3rd form in front.

However, there are about 40 forms in this app, and I
didn't write it, so it is very time-consuming to find and
fix these errors.

I am not convinced this is the only source of this error
or that this is the root source.

For example, I could not reproduce the error in Access
2003 running on my Windows XP dev machine (with dev
database copy on local machine as well). But I replaced
all references to currentDB with dbEngine(0)(0), and
defined all variables that store recordsets as recordsets
(previously they were just dim'd, so they would be
variants).

After making these fixes, I then was able to reproduce
the users' reported problems on my machine! I then
investigated further and found that by getting rid of the
subform before popping another 3rd form or window in
front of it, and then restoring the subform *after* focus
was firmly returned to the primary form.

However, this would have to be applied everywhere there
is a form and subform and dialog is popped in front.

Is there any way to restore the prior behavior?
 
Splitting
If several users are accessing this database, consider splitting so the back
end resides on the server (mdb with tables only), and
each user has their own local copy of the front end (queries, form, reports,
code, and attached tables). This is really important to solve concurrency
problems.

Network Issues
- Also worth checking the network connects are all really tight hardware
connections, no flakey stuff (such asWiFi).

- You say that the latest service packs are applied, and Window 2000 SP3 was
supposed to disable the Opportunistic Locking which is known to cause
problems with Access. May be worth checking that the setting is disabled.

Timing Issues
Access has always loaded the subforms into memory before the main form, so
I'm not sure why this would make a difference under Win2000.
- Do you have timing-sensitive code in the Open, Load, or Activate events of
the form or subform?
- Does the RecordSource or your form/subform contain a reference to the
form/subform (e.g. " ... WHERE [SomeField] = Forms!... ")?

Recordsets
DAO and ADO both have Recordset objects, so be very explicit with your
declarations, e.g.:
Dim rs As DAO.Recordset
It's worth finding all of these and fixing them. You also need to ensure
that you close the ones you open (don't close RecordsetClones), and set all
object variables to Nothing (even after error recovery). If you use DAO
transactions anywhere, see the Traps section of this article:
http://allenbrowne.com/ser-37.html

Debugging
Before a break point where you expect a transient error masked by error
handling, you can use:
Debug.Print Err.Number, Err.Description
Better still, log your errors. Example:
http://allenbrowne.com/ser-23a.html

Hope something amongst that makes your task easier.
 
Allen said:
Timing Issues
- Do you have timing-sensitive code in the Open, Load, or Activate events of
the form or subform?
- Does the RecordSource or your form/subform contain a reference to the
form/subform (e.g. " ... WHERE [SomeField] = Forms!... ")?
Click to expand...

You know, the one thing I hadn't considered is that the new machines
with Win2K are much faster than the old ones with Win98.

That would be another explanation for why breakpoints prevent the error.

There's lots of code in the open, load, and current events.

And maybe (as you say) the recordsource is referring to a field in the
form/subform and now on faster machines, the recordsource is getting
instantiated before the form has fully come up (?), resulting in the
"object not found" and "too complex or not found" errors.

Hmmmmm....

I wonder what would happen if I put a sleep(1000) in front of all the
"set rs=" 's?

I didn't write the app, and there are many things written in ways that
may work but aren't good practice.

The problem is that this app has a lot of forms and it is written
consistently in the same manner but not really calling a lot of library
code.
 
Back
Top