Null MDE / MDB failure

  • Thread starter Thread starter Dave
  • Start date Start date
D

Dave

We develop and sell an access application and have several dozen sites and
clients using the system. We develop in Access XP in Access 2k format, but
distribute the app in MDE format. We use Access 2k to get to the MDE format
and use one particular PC to do this. That PC has Access 2k, XP & 2003
loaded. We have done this many many times over a period of several years
with no problems at all.

In recent days however, we have found the mde fails, but only for some
clients. If we take the mdb file and convert it to a mde on another PC all
is well and it does not fail.

The failure occurs on startup and the error message refers to a field (that
is not referred to in the startup routine at all) being not able to be null
(even though it is not)

There appears to be no pattern of which systems fail, except that so far
they have all been Win XP Pro using Access XP (either Run time or the full
version). Though not all XP Pro OS's fail.

Any ideas?

Thanks

Dave
 
Dave, I'm not sure I have a solution for this intermittent issue, so
hopefully others will contribute also.

The fact that the failing code refers to a field that is not even in the
code and the message is inappropriate suggests that Access is confused or
the database is corrupted. Suggestions:

1. Name AutoCorrect
You probably already know about the plethora of issues caused by this
misfeature, including Access mis-identifying objects. Uncheck the boxes
under:
Tools | Options | General
More info:
http://allenbrowne.com/bug-03.html

2. Compilation errors
We have found that intermittent errors are relatively common if you develop
in one version and then convert back to a previous one. It has to do with
the fact that the compiled code is different in each version of Access, and
the solution is to decompile in the version you have been working with, then
compact without compiling or changing any code (which would cause an
implicit compile). Then open the database in the older version and compile
there.

To decompile, enter something like this at the command prompt while Access
is not running. It is all one line, and include the quotes:
"c:\Program Files\Microsoft office\office\msaccess.exe" /decompile
"c:\MyPath\MyDatabase.mdb"

3. References/versions
If the first two suggestions do not fix the issue, look for version
differences on the machines that do fail. This is such an issue now that we
include routines on our custom Help | About screen that return the version
numbers for the msaccess.exe and msjet40.dll. You can use the API calls in
these pages to display the versions, and the user can then read them to you
in a support call to identify whether the machine is up to date:
http://www.mvps.org/access/api/api0065.htm
http://www.mvps.org/access/api/api0010.htm
It is possible that the referenced files are incorrect also, but the
built-in ones (VBA, Access, and DAO 3.6) should be right if the minor
version of msaccess.exe is up to date, and you will know if you have to
handle other referenced dll's.

There are some other weird behaviours that result from the user not having
sufficient permissions, but that does not sound like your issues.

HTH
 
Allen

Thnks for your help.

1. Yes we do know about the auto correct - all machines have this switched
off - and have had so for some time (certainly long before this problem
raised itself)

2. I was aware of the decompile and have carried it out on occasion - but
not for some time - so will decompile and see if it helps

3. References was where I first went to try and solve the problem - so will
revisit

Agreed don't think it is a permissions error

Will let you know how it goes

Dave
 
Back
Top