Re: Null MDE / MDB failure
- From: "Allen Browne" <AllenBrowne@xxxxxxxxxxxxxx>
- Date: Fri, 1 Apr 2005 23:15:58 +0800
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 Browne - Microsoft MVP. Perth, Western Australia.
Tips for Access users - http://allenbrowne.com/tips.html
Reply to group, rather than allenbrowne at mvps dot org.
"Dave" <strategicdelivery@xxxxxxxxxx> wrote in message
news:d2inrh$er2$1@xxxxxxxxxxxxxxxxxx
> 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
.
- Follow-Ups:
- Re: Null MDE / MDB failure
- From: Dave
- Re: Null MDE / MDB failure
- References:
- Null MDE / MDB failure
- From: Dave
- Null MDE / MDB failure
- Prev by Date: Re: Text box change when combo box change
- Next by Date: Re: Show current information in a Form
- Previous by thread: Null MDE / MDB failure
- Next by thread: Re: Null MDE / MDB failure
- Index(es):
Relevant Pages
|
