Re: Null MDE / MDB failure

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

"Allen Browne" <AllenBrowne@xxxxxxxxxxxxxx> wrote in message
news:u33N42sNFHA.1172@xxxxxxxxxxxxxxxxxxxxxxx
> 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
>
>


.