MDE Problem

[Christine]

I have an application which I deploy as an MDE file to many end users.

The application generally works as expected but two of my users have had the
same problem which I have managed to rectify by simply replacing the MDE file
(ie. re-installing the original application with no changes to files on the
computer or the application).

The application functions correctly but then "unexpectedly" a part of the
application which previously worked suddenly ceases to work. As both users
experienced the same problem in the same part of the application, I am
curious as to why the problem is occurring and what I can do to prevent the
problem. It also means that other users could potentially get the same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first installed.
2. The problem occurs “unpredictablyâ€.
3. The problem is fixed by simply replacing the mde file with the original
mde file.
4. When the "faulty" mde file is transferred to another machine, the problem
still exists. It appears to me that the mde file is somehow corrupted but I
can’t understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting produced
the following error:.

*The expression may not result in the name of a macro, the name of a user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or macro.


This indicates to me a ‘reference file problem’ but as the problem does not
exist in the original mdb or mde file, I have no means of proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the problem
would be very much appreciated!

 

[Geoff]

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong with the
value entered in an event property. It seems that, because a value has been
entered (in an event property), Access is raising the event and is trying to
run either a macro, user-defined function, or event procedure - but it can't
(perhaps because the macro or function is incorrectly named in the property)
or the said macro, function or event procedure is running but is returning
an invalid value or is trying to do something that the users don't have the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users (on
the same and different machines). Try to pinpoint the difference between
the good and bad environments.

Regards
Geoff

I have an application which I deploy as an MDE file to many end users.

The application generally works as expected but two of my users have had
the
same problem which I have managed to rectify by simply replacing the MDE
file
(ie. re-installing the original application with no changes to files on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part of the
application which previously worked suddenly ceases to work. As both
users
experienced the same problem in the same part of the application, I am
curious as to why the problem is occurring and what I can do to prevent
the
problem. It also means that other users could potentially get the same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow corrupted but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting produced
the following error:.

*The expression may not result in the name of a macro, the name of a user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or macro.


This indicates to me a 'reference file problem' but as the problem does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the problem
would be very much appreciated!

 

[AccessVandal via AccessMonster.com]

Hi Christine,

This indicates to me a ‘reference file problem’ but as the problem does not
exist in the original mdb or mde file, I have no means of proving/debugging
the application to isolate the problem.

I may not be getting what you mean on the above.

Anyway, have you tried to complie the code and make MDE on the User PC?

The User PC may not have the proper referances needed in their PC.

 

[Christine]

Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two users
who are experiencing this problem are generating the same offending event,
which only runs in certain circumstances giving the unpredicable appearance
to the problem?" is interesting because one the things that crossed my mine
was that they had installed something or did something to their computer
environment which affected a DLL or reference file BUT if that is the case
then why does it work without me re-linking or re-registering the file? A
point to note is that my users are generally lay/homebased users with little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed with MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working' version and
a 'non-working' version is the mde (and as mentioned I re-deploy the original
without changes). When the 'bad' MDE is transferred to my development m/c it
produces the same error with both the full version of MS access and the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong with the
value entered in an event property. It seems that, because a value has been
entered (in an event property), Access is raising the event and is trying to
run either a macro, user-defined function, or event procedure - but it can't
(perhaps because the macro or function is incorrectly named in the property)
or the said macro, function or event procedure is running but is returning
an invalid value or is trying to do something that the users don't have the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users (on
the same and different machines). Try to pinpoint the difference between
the good and bad environments.

Regards
Geoff

I have an application which I deploy as an MDE file to many end users.

The application generally works as expected but two of my users have had
the
same problem which I have managed to rectify by simply replacing the MDE
file
(ie. re-installing the original application with no changes to files on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part of the
application which previously worked suddenly ceases to work. As both
users
experienced the same problem in the same part of the application, I am
curious as to why the problem is occurring and what I can do to prevent
the
problem. It also means that other users could potentially get the same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow corrupted but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting produced
the following error:.

*The expression may not result in the name of a macro, the name of a user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or macro.


This indicates to me a 'reference file problem' but as the problem does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the problem
would be very much appreciated!

 

[Christine]

Hi,

As mentioned in earlier post to Geoff - users are lay users and not likely
to have full version of Microsoft Access on their machine but also I don't
think it will not solve the problem. All the necessary files were present
before the problem occurred and no changes were made to the computer to fix
the problem (only replaced faulty mde file).

 

[Geoff]

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte check
between a "corrupted" MDE file and a good MDE file? (You could probably
download a freeware utility from www.zdnet.com.) That check would at least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or reports. As
you know, any attempt to do this would run into trouble (a) because you
can't do that with the Runtime verion of Access and (b) because you can't do
that anyway with an MDE file. Is it possible that the database makes such an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant but does
the database attempt to create or modify any queries behind forms, combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few further
thoughts.

Good luck with it!
Regards
Geoff

Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two users
who are experiencing this problem are generating the same offending event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed my
mine
was that they had installed something or did something to their computer
environment which affected a DLL or reference file BUT if that is the case
then why does it work without me re-linking or re-registering the file?
A
point to note is that my users are generally lay/homebased users with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed with MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working' version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my development m/c
it
produces the same error with both the full version of MS access and the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong with
the
value entered in an event property. It seems that, because a value has
been
entered (in an event property), Access is raising the event and is trying
to
run either a macro, user-defined function, or event procedure - but it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the
two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users (on
the same and different machines). Try to pinpoint the difference between
the good and bad environments.

Regards
Geoff

I have an application which I deploy as an MDE file to many end users.

The application generally works as expected but two of my users have
had
the
same problem which I have managed to rectify by simply replacing the
MDE
file
(ie. re-installing the original application with no changes to files on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part of
the
application which previously worked suddenly ceases to work. As both
users
experienced the same problem in the same part of the application, I am
curious as to why the problem is occurring and what I can do to prevent
the
problem. It also means that other users could potentially get the same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or macro.


This indicates to me a 'reference file problem' but as the problem does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the problem
would be very much appreciated!

 

[Christine]

Ok - I do keep a number of temporary tables in the MDE with the code but
certainly do not attempt to change any aspect of the application design
within the mde.

I did try to test this by replacing the temporary tables with those from a
working version to see whether it made any difference but unfortunately not
(although perhaps writing to the tables managed to corrupt some of the
code????!!!!!! - I guess anythings possible!).

Thanks for your comments - it helps to get a second opinion.....

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte check
between a "corrupted" MDE file and a good MDE file? (You could probably
download a freeware utility from www.zdnet.com.) That check would at least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or reports. As
you know, any attempt to do this would run into trouble (a) because you
can't do that with the Runtime verion of Access and (b) because you can't do
that anyway with an MDE file. Is it possible that the database makes such an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant but does
the database attempt to create or modify any queries behind forms, combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few further
thoughts.

Good luck with it!
Regards
Geoff

Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two users
who are experiencing this problem are generating the same offending event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed my
mine
was that they had installed something or did something to their computer
environment which affected a DLL or reference file BUT if that is the case
then why does it work without me re-linking or re-registering the file?
A
point to note is that my users are generally lay/homebased users with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed with MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working' version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my development m/c
it
produces the same error with both the full version of MS access and the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong with
the
value entered in an event property. It seems that, because a value has
been
entered (in an event property), Access is raising the event and is trying
to
run either a macro, user-defined function, or event procedure - but it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the
two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users (on
the same and different machines). Try to pinpoint the difference between
the good and bad environments.

Regards
Geoff


I have an application which I deploy as an MDE file to many end users.

The application generally works as expected but two of my users have
had
the
same problem which I have managed to rectify by simply replacing the
MDE
file
(ie. re-installing the original application with no changes to files on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part of
the
application which previously worked suddenly ceases to work. As both
users
experienced the same problem in the same part of the application, I am
curious as to why the problem is occurring and what I can do to prevent
the
problem. It also means that other users could potentially get the same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or macro.


This indicates to me a 'reference file problem' but as the problem does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the problem
would be very much appreciated!

 

[AccessVandal via AccessMonster.com]

Hi Christine,

I don’t know whether these will help you solve the problems.

Did you try a recomplie the RunTime Version?

Did users have upgraded their IE6 to IE7? There was a case of IE7 problem
related to Access being case sensitive last week and other problems.

 

[Christine]

Hi,

Not sure what your mean by recompiling the RT version? I recompiled the
original MDE and it works.

One user encountered the problem in early October and the second about a
week ago. So I don't think it has anything to do with the upgrade from IE6
to IE7. Only just started looking at it since I think that it must be more
than a co-incidence that the problems are identical.

 

[AccessVandal via AccessMonster.com]

Hi Christine

Not sure what your mean by recompiling the RT version? I recompiled the
original MDE and it works.

I am referring to the Developer Edition of Access where you created this
RunTime that was installed for the Users without full version of Access.

One user encountered the problem in early October and the second about a
week ago. So I don't think it has anything to do with the upgrade from IE6
to IE7. Only just started looking at it since I think that it must be more
than a co-incidence that the problems are identical.

If its not IE or RunTime or your code, and you did try to compile the MDE and
try to replicate the error with a Full version of Access on the User PC, then
I’m out of ideas.

 

[Geoff]

Christine:

I typed the first part of the error message you quoted, ie:

The expression on click you entered as the event property setting produced
the following error

into the Microsoft website and bingo! It returned 13 hits.

The following hyperlink looks interesting as it contains the whole of your
error message. It applies when a user opens an older Access database in
Access 2007 and tries to open a table in design mode. The resolution to the
problem is to rename the form or report that has the same name as a table:

http://support.microsoft.com/kb/926700

I didn't examine any other of the 13 hits. If the above isn't it, you might
like to do a similar search. Hope this leads somewhere...

Regards
Geoff

Ok - I do keep a number of temporary tables in the MDE with the code but
certainly do not attempt to change any aspect of the application design
within the mde.

I did try to test this by replacing the temporary tables with those from a
working version to see whether it made any difference but unfortunately
not
(although perhaps writing to the tables managed to corrupt some of the
code????!!!!!! - I guess anythings possible!).

Thanks for your comments - it helps to get a second opinion.....

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte
check
between a "corrupted" MDE file and a good MDE file? (You could probably
download a freeware utility from www.zdnet.com.) That check would at
least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or reports.
As
you know, any attempt to do this would run into trouble (a) because you
can't do that with the Runtime verion of Access and (b) because you can't
do
that anyway with an MDE file. Is it possible that the database makes such
an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant but
does
the database attempt to create or modify any queries behind forms, combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few
further
thoughts.

Good luck with it!
Regards
Geoff

Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two
users
who are experiencing this problem are generating the same offending
event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed my
mine
was that they had installed something or did something to their
computer
environment which affected a DLL or reference file BUT if that is the
case
then why does it work without me re-linking or re-registering the file?
A
point to note is that my users are generally lay/homebased users with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed with
MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working' version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my development
m/c
it
produces the same error with both the full version of MS access and the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

:

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem
are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong
with
the
value entered in an event property. It seems that, because a value has
been
entered (in an event property), Access is raising the event and is
trying
to
run either a macro, user-defined function, or event procedure - but it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't
have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the
two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users
(on
the same and different machines). Try to pinpoint the difference
between
the good and bad environments.

Regards
Geoff


I have an application which I deploy as an MDE file to many end
users.

The application generally works as expected but two of my users have
had
the
same problem which I have managed to rectify by simply replacing the
MDE
file
(ie. re-installing the original application with no changes to files
on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part
of
the
application which previously worked suddenly ceases to work. As
both
users
experienced the same problem in the same part of the application, I
am
curious as to why the problem is occurring and what I can do to
prevent
the
problem. It also means that other users could potentially get the
same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first
installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow
corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or
macro.


This indicates to me a 'reference file problem' but as the problem
does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the
problem
would be very much appreciated!

 

[Christine]

I did originally try to look up the error in the User Group postings but did
not find anything. I will check again including the Microsoft site. Thanks
for your help.

Christine:

I typed the first part of the error message you quoted, ie:

The expression on click you entered as the event property setting produced
the following error

into the Microsoft website and bingo! It returned 13 hits.

The following hyperlink looks interesting as it contains the whole of your
error message. It applies when a user opens an older Access database in
Access 2007 and tries to open a table in design mode. The resolution to the
problem is to rename the form or report that has the same name as a table:

http://support.microsoft.com/kb/926700

I didn't examine any other of the 13 hits. If the above isn't it, you might
like to do a similar search. Hope this leads somewhere...

Regards
Geoff

Ok - I do keep a number of temporary tables in the MDE with the code but
certainly do not attempt to change any aspect of the application design
within the mde.

I did try to test this by replacing the temporary tables with those from a
working version to see whether it made any difference but unfortunately
not
(although perhaps writing to the tables managed to corrupt some of the
code????!!!!!! - I guess anythings possible!).

Thanks for your comments - it helps to get a second opinion.....

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte
check
between a "corrupted" MDE file and a good MDE file? (You could probably
download a freeware utility from www.zdnet.com.) That check would at
least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or reports.
As
you know, any attempt to do this would run into trouble (a) because you
can't do that with the Runtime verion of Access and (b) because you can't
do
that anyway with an MDE file. Is it possible that the database makes such
an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant but
does
the database attempt to create or modify any queries behind forms, combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few
further
thoughts.

Good luck with it!
Regards
Geoff


Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two
users
who are experiencing this problem are generating the same offending
event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed my
mine
was that they had installed something or did something to their
computer
environment which affected a DLL or reference file BUT if that is the
case
then why does it work without me re-linking or re-registering the file?
A
point to note is that my users are generally lay/homebased users with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed with
MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working' version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my development
m/c
it
produces the same error with both the full version of MS access and the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

:

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem
are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong
with
the
value entered in an event property. It seems that, because a value has
been
entered (in an event property), Access is raising the event and is
trying
to
run either a macro, user-defined function, or event procedure - but it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't
have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the
two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users
(on
the same and different machines). Try to pinpoint the difference
between
the good and bad environments.

Regards
Geoff


I have an application which I deploy as an MDE file to many end
users.

The application generally works as expected but two of my users have
had
the
same problem which I have managed to rectify by simply replacing the
MDE
file
(ie. re-installing the original application with no changes to files
on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part
of
the
application which previously worked suddenly ceases to work. As
both
users
experienced the same problem in the same part of the application, I
am
curious as to why the problem is occurring and what I can do to
prevent
the
problem. It also means that other users could potentially get the
same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first
installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow
corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or
macro.


This indicates to me a 'reference file problem' but as the problem
does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the
problem
would be very much appreciated!

 

[Christine]

Found the problem!

I unlocked the MDE file and discovered a temporary query which was suppose
to be deleted still in the file. I deleted the query, re-locked the MDE and
to my surprise it started working again!

The part of the program that failed, dynamically builds a SQL string
comprising 'user options' for record selection. I use the query as a
recordsource for one of my subforms. I'm not sure why it failed as I tested
the query and it worked okay but at least I know what is causing it and can
investigate further.

Christine:

I typed the first part of the error message you quoted, ie:

The expression on click you entered as the event property setting produced
the following error

into the Microsoft website and bingo! It returned 13 hits.

The following hyperlink looks interesting as it contains the whole of your
error message. It applies when a user opens an older Access database in
Access 2007 and tries to open a table in design mode. The resolution to the
problem is to rename the form or report that has the same name as a table:

http://support.microsoft.com/kb/926700

I didn't examine any other of the 13 hits. If the above isn't it, you might
like to do a similar search. Hope this leads somewhere...

Regards
Geoff

Ok - I do keep a number of temporary tables in the MDE with the code but
certainly do not attempt to change any aspect of the application design
within the mde.

I did try to test this by replacing the temporary tables with those from a
working version to see whether it made any difference but unfortunately
not
(although perhaps writing to the tables managed to corrupt some of the
code????!!!!!! - I guess anythings possible!).

Thanks for your comments - it helps to get a second opinion.....

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte
check
between a "corrupted" MDE file and a good MDE file? (You could probably
download a freeware utility from www.zdnet.com.) That check would at
least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or reports.
As
you know, any attempt to do this would run into trouble (a) because you
can't do that with the Runtime verion of Access and (b) because you can't
do
that anyway with an MDE file. Is it possible that the database makes such
an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant but
does
the database attempt to create or modify any queries behind forms, combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few
further
thoughts.

Good luck with it!
Regards
Geoff


Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two
users
who are experiencing this problem are generating the same offending
event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed my
mine
was that they had installed something or did something to their
computer
environment which affected a DLL or reference file BUT if that is the
case
then why does it work without me re-linking or re-registering the file?
A
point to note is that my users are generally lay/homebased users with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed with
MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working' version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my development
m/c
it
produces the same error with both the full version of MS access and the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

:

This is only a guess. I hope someone else has a better answer for you.

Is it possible that the two users who are experiencing this problem
are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong
with
the
value entered in an event property. It seems that, because a value has
been
entered (in an event property), Access is raising the event and is
trying
to
run either a macro, user-defined function, or event procedure - but it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't
have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is the
two
users are doing when the problem arises and then replicate that action
logged in as an Admin user and then logged in as one of the two users
(on
the same and different machines). Try to pinpoint the difference
between
the good and bad environments.

Regards
Geoff


I have an application which I deploy as an MDE file to many end
users.

The application generally works as expected but two of my users have
had
the
same problem which I have managed to rectify by simply replacing the
MDE
file
(ie. re-installing the original application with no changes to files
on
the
computer or the application).

The application functions correctly but then "unexpectedly" a part
of
the
application which previously worked suddenly ceases to work. As
both
users
experienced the same problem in the same part of the application, I
am
curious as to why the problem is occurring and what I can do to
prevent
the
problem. It also means that other users could potentially get the
same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first
installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine, the
problem
still exists. It appears to me that the mde file is somehow
corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or
macro.


This indicates to me a 'reference file problem' but as the problem
does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the
problem
would be very much appreciated!

 

[Geoff]

Christine:

Well done! It must be satisfying to be on the way to cracking it.

I remember a problem I came across some time back. I was OK if I amended
the SQL statement behind a query, (and if did not delete and recreate the
query). Then I could leave the query name unchanged in the RecordSource
property of the form. But I seem to recall I wasn't OK if I deleted and
recreated the query each time or if I tried to write a new SQL statement or
query name into a RecordSource property.

Not sure how your application works, but instead of having a temporary query
as the recordsource for your subform, maybe you should turn it into a
permanent query and then, after gathering user imput (ie criteria) for the
query, open the permanent query in your VBA code and amend its SQL statement
and save the query again before allowing the main form to open. This would
avoid editing the subform. Just a suggestion, but as I say, I don't know how
your application works.

Regards
Geoff.

Found the problem!

I unlocked the MDE file and discovered a temporary query which was suppose
to be deleted still in the file. I deleted the query, re-locked the MDE
and
to my surprise it started working again!

The part of the program that failed, dynamically builds a SQL string
comprising 'user options' for record selection. I use the query as a
recordsource for one of my subforms. I'm not sure why it failed as I
tested
the query and it worked okay but at least I know what is causing it and
can
investigate further.

Christine:

I typed the first part of the error message you quoted, ie:

The expression on click you entered as the event property setting
produced
the following error

into the Microsoft website and bingo! It returned 13 hits.

The following hyperlink looks interesting as it contains the whole of
your
error message. It applies when a user opens an older Access database in
Access 2007 and tries to open a table in design mode. The resolution to
the
problem is to rename the form or report that has the same name as a
table:

http://support.microsoft.com/kb/926700

I didn't examine any other of the 13 hits. If the above isn't it, you
might
like to do a similar search. Hope this leads somewhere...

Regards
Geoff

Ok - I do keep a number of temporary tables in the MDE with the code
but
certainly do not attempt to change any aspect of the application design
within the mde.

I did try to test this by replacing the temporary tables with those
from a
working version to see whether it made any difference but unfortunately
not
(although perhaps writing to the tables managed to corrupt some of the
code????!!!!!! - I guess anythings possible!).

Thanks for your comments - it helps to get a second opinion.....



:

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte
check
between a "corrupted" MDE file and a good MDE file? (You could
probably
download a freeware utility from www.zdnet.com.) That check would at
least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or
reports.
As
you know, any attempt to do this would run into trouble (a) because
you
can't do that with the Runtime verion of Access and (b) because you
can't
do
that anyway with an MDE file. Is it possible that the database makes
such
an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant
but
does
the database attempt to create or modify any queries behind forms,
combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property
of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few
further
thoughts.

Good luck with it!
Regards
Geoff


Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two
users
who are experiencing this problem are generating the same offending
event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed
my
mine
was that they had installed something or did something to their
computer
environment which affected a DLL or reference file BUT if that is
the
case
then why does it work without me re-linking or re-registering the
file?
A
point to note is that my users are generally lay/homebased users
with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed
with
MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working'
version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my
development
m/c
it
produces the same error with both the full version of MS access and
the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

:

This is only a guess. I hope someone else has a better answer for
you.

Is it possible that the two users who are experiencing this problem
are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong
with
the
value entered in an event property. It seems that, because a value
has
been
entered (in an event property), Access is raising the event and is
trying
to
run either a macro, user-defined function, or event procedure - but
it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't
have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is
the
two
users are doing when the problem arises and then replicate that
action
logged in as an Admin user and then logged in as one of the two
users
(on
the same and different machines). Try to pinpoint the difference
between
the good and bad environments.

Regards
Geoff


I have an application which I deploy as an MDE file to many end
users.

The application generally works as expected but two of my users
have
had
the
same problem which I have managed to rectify by simply replacing
the
MDE
file
(ie. re-installing the original application with no changes to
files
on
the
computer or the application).

The application functions correctly but then "unexpectedly" a
part
of
the
application which previously worked suddenly ceases to work. As
both
users
experienced the same problem in the same part of the application,
I
am
curious as to why the problem is occurring and what I can do to
prevent
the
problem. It also means that other users could potentially get
the
same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first
installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine,
the
problem
still exists. It appears to me that the mde file is somehow
corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name
of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or
macro.


This indicates to me a 'reference file problem' but as the
problem
does
not
exist in the original mdb or mde file, I have no means of
proving/debugging
the application to isolate the problem.

Any comments on why this is happening and how I can prevent the
problem
would be very much appreciated!

 

[Christine]

I dynamically change the recordsource in a number of places in my application
but this is the only place that Creates, Saves and Deletes a QueryDef Object.
A comment in my code suggests that the reason I did it was because I could
not set the SQL string directly to the recordsource property because it was
too long.

At least now that I know where the problem lies I can change the way it
works- perhaps making the Query permanent as you suggest.

Thanks for your thoughts. Back to development.
Cheers,

Christine:

Well done! It must be satisfying to be on the way to cracking it.

I remember a problem I came across some time back. I was OK if I amended
the SQL statement behind a query, (and if did not delete and recreate the
query). Then I could leave the query name unchanged in the RecordSource
property of the form. But I seem to recall I wasn't OK if I deleted and
recreated the query each time or if I tried to write a new SQL statement or
query name into a RecordSource property.

Not sure how your application works, but instead of having a temporary query
as the recordsource for your subform, maybe you should turn it into a
permanent query and then, after gathering user imput (ie criteria) for the
query, open the permanent query in your VBA code and amend its SQL statement
and save the query again before allowing the main form to open. This would
avoid editing the subform. Just a suggestion, but as I say, I don't know how
your application works.

Regards
Geoff.

Found the problem!

I unlocked the MDE file and discovered a temporary query which was suppose
to be deleted still in the file. I deleted the query, re-locked the MDE
and
to my surprise it started working again!

The part of the program that failed, dynamically builds a SQL string
comprising 'user options' for record selection. I use the query as a
recordsource for one of my subforms. I'm not sure why it failed as I
tested
the query and it worked okay but at least I know what is causing it and
can
investigate further.

Christine:

I typed the first part of the error message you quoted, ie:

The expression on click you entered as the event property setting
produced
the following error

into the Microsoft website and bingo! It returned 13 hits.

The following hyperlink looks interesting as it contains the whole of
your
error message. It applies when a user opens an older Access database in
Access 2007 and tries to open a table in design mode. The resolution to
the
problem is to rename the form or report that has the same name as a
table:

http://support.microsoft.com/kb/926700

I didn't examine any other of the 13 hits. If the above isn't it, you
might
like to do a similar search. Hope this leads somewhere...

Regards
Geoff



Ok - I do keep a number of temporary tables in the MDE with the code
but
certainly do not attempt to change any aspect of the application design
within the mde.

I did try to test this by replacing the temporary tables with those
from a
working version to see whether it made any difference but unfortunately
not
(although perhaps writing to the tables managed to corrupt some of the
code????!!!!!! - I guess anythings possible!).

Thanks for your comments - it helps to get a second opinion.....



:

Christine:

I agree - it is confusing!

The implication of what you say seems to be that the MDE file has been
modified and corrupted.

If that is your suspicion; and if the MDE file is storing data in a
different (eg backend) file (implying that the MDE file should never
change), do you have a file compare utility that'll do a byte-for-byte
check
between a "corrupted" MDE file and a good MDE file? (You could
probably
download a freeware utility from www.zdnet.com.) That check would at
least
tell you if something's amiss with the MDE file.

I take it the database doesn't try to modify any of the forms or
reports.
As
you know, any attempt to do this would run into trouble (a) because
you
can't do that with the Runtime verion of Access and (b) because you
can't
do
that anyway with an MDE file. Is it possible that the database makes
such
an
attempt and this corrupts the MDE file?

I'm not sure if there are circumstances when this might be relevant
but
does
the database attempt to create or modify any queries behind forms,
combo
boxes, listboxes, or reports at runtime? I'm thinking perhaps if the
database tried to put a new SQL statement in the Row Source property
of a
combobox on a form, for instance, that might lead to trouble.

Again, this isn't my area of expertise so the above are only a few
further
thoughts.

Good luck with it!
Regards
Geoff


Hi Geoff,

Thanks for your thoughts. Your comment "Is it possible that the two
users
who are experiencing this problem are generating the same offending
event,
which only runs in certain circumstances giving the unpredicable
appearance
to the problem?" is interesting because one the things that crossed
my
mine
was that they had installed something or did something to their
computer
environment which affected a DLL or reference file BUT if that is
the
case
then why does it work without me re-linking or re-registering the
file?
A
point to note is that my users are generally lay/homebased users
with
little
computer experience. Also the application is deployed into
'unknown/uncontrolled' environments so the application is deployed
with
MS
Access Runtime.

Unfortunately, the only factor that differs between a 'working'
version
and
a 'non-working' version is the mde (and as mentioned I re-deploy the
original
without changes). When the 'bad' MDE is transferred to my
development
m/c
it
produces the same error with both the full version of MS access and
the
Access Runtime. Confusing heh????!!!! I am stomped!!!!

:

This is only a guess. I hope someone else has a better answer for
you.

Is it possible that the two users who are experiencing this problem
are
generating the same offending event, which only runs in certain
circumstances giving the unpredicable appearance to the problem?

The error message seems to imply that there may be something wrong
with
the
value entered in an event property. It seems that, because a value
has
been
entered (in an event property), Access is raising the event and is
trying
to
run either a macro, user-defined function, or event procedure - but
it
can't
(perhaps because the macro or function is incorrectly named in the
property)
or the said macro, function or event procedure is running but is
returning
an invalid value or is trying to do something that the users don't
have
the
rights to do.

It seems a way forward might be to ask yourself what exactly it is
the
two
users are doing when the problem arises and then replicate that
action
logged in as an Admin user and then logged in as one of the two
users
(on
the same and different machines). Try to pinpoint the difference
between
the good and bad environments.

Regards
Geoff


I have an application which I deploy as an MDE file to many end
users.

The application generally works as expected but two of my users
have
had
the
same problem which I have managed to rectify by simply replacing
the
MDE
file
(ie. re-installing the original application with no changes to
files
on
the
computer or the application).

The application functions correctly but then "unexpectedly" a
part
of
the
application which previously worked suddenly ceases to work. As
both
users
experienced the same problem in the same part of the application,
I
am
curious as to why the problem is occurring and what I can do to
prevent
the
problem. It also means that other users could potentially get
the
same
problem.

It baffles me how and why this could happen as:
1. The problem did not exist when the application was first
installed.
2. The problem occurs "unpredictably".
3. The problem is fixed by simply replacing the mde file with the
original
mde file.
4. When the "faulty" mde file is transferred to another machine,
the
problem
still exists. It appears to me that the mde file is somehow
corrupted
but
I
can't understand how this could happen as it is compiled code.

When the problem occurs, users get the following message:

The expression on click you entered as the event property setting
produced
the following error:.

*The expression may not result in the name of a macro, the name
of a
user
defined function, or [event procedure].
*There may have been an error evaluating the function, event or
macro.


This indicates to me a 'reference file problem' but as the
problem
does