Runtime errors after office 365 version update

So, I finally have some extra info to add to this, although not sure I actually understand what is going on....


I found this old thread that sounded almost exactly like my problem and did some investigation into enabling/disabling special keys.


Tested on my application and when enabled (not the default) with Version 2304 (Build 16327.20248) the runtime errors are flagged, but when disabling (which was the default) they are not.

However in the newer Version, they are flagged regardless of whether this is enabled or disabled.

Does this give anyone who knows access inside out any further ideas?

Thanks,

Tom
 
The default is to Allow Special Keys.
There was a change in v2305 regarding breakpoints and special keys. See my article

This also links back to the MS article mentioned in post #4. Please read to see whether that is relevant to your ongoing issues
 
The default is to Allow Special Keys.
There was a change in v2305 regarding breakpoints and special keys. See my article

This also links back to the MS article mentioned in post #4. Please read to see whether that is relevant to your ongoing issues

Thanks for the reply.

The default for this application was always special keys disabled (for exactly this reason I imagine).

I have updated access to the very latest version, but still the same problem.

But I can toggle the special keys setting on/off with v2304 and get the program to run ignoring runtime errors, or flagging them.

Something isn't right here, as absolutely nothing changed bar the access version.

(nb. I also looked for an autoexec macro as you suggested last week, but there is not one, all access settings/check boxes are identical across both versions of access and there is no code on start up and load of application that pertains to error handling either.)
 
As already mentioned, the Access default is to allow special keys.
When that option is disabled, it is normally for security reasons. The breakpoint issue (now fixed) was an unintended side effect

After 43 posts, we need a way of getting past this point.
Excuse me for not spending time checking back over the entire thread but have you tried
1. Checking for phantom breakpoints
2. decompiling to remove any corrupted code
3. Importing all objects into a new database

If all the above have been tested and didn't help, then I suggest you make a cut down version removing all sensitive data and upload here for others to test
 
As already mentioned, the Access default is to allow special keys.
When that option is disabled, it is normally for security reasons. The breakpoint issue (now fixed) was an unintended side effect

After 43 posts, we need a way of getting past this point.
Excuse me for not spending time checking back over the entire thread but have you tried
1. Checking for phantom breakpoints
2. decompiling to remove any corrupted code
3. Importing all objects into a new database

If all the above have been tested and didn't help, then I suggest you make a cut down version removing all sensitive data and upload here for others to test

Hi,

I don't think I am explaining very well...

The errors are known errors that are basically irrelevant to my application, but the messages they generate were being supressed before and now they are not and that is what I am trying to understand.

I went years without even realising there was bad code in there because they were being suppressed.

As I say, the only thing that has changed, is updating access versions.

Cheers
 
Hi,

I don't think I am explaining very well...

The errors are known errors that are basically irrelevant to my application, but the messages they generate were being supressed before and now they are not and that is what I am trying to understand.

I went years without even realising there was bad code in there because they were being suppressed.

As I say, the only thing that has changed, is updating access versions.

Cheers
You stated at the start of this thread that the actual errors were irrelevant. I disagreed then & stated why.

Over the years, Access has become more intolerant of poor code which is overall a good thing.
Perhaps something specific in version 2305 has triggered errors to now be shown.
I have offered at least one possible cause & also suggested things that may help, as have other AWF members including a long standing member of the Access team

if you don't want to follow up on advice given, that's fine, but if that is the case, I may as well drop out of this thread.
 
You stated at the start of this thread that the actual errors were irrelevant. I disagreed then & stated why.

Over the years, Access has become more intolerant of poor code which is overall a good thing.
Perhaps something specific in version 2305 has triggered errors to now be shown.
I have offered at least one possible cause & also suggested things that may help, as have other AWF members including a long standing member of the Access team

if you don't want to follow up on advice given, that's fine, but if that is the case, I may as well drop out of this thread.

I guess I can just put 'on error resume next' to stop them popping up and confusing people, but that still does not address why they are suddenly appearing after a decade plus of being suppressed on standard start-up of the application.

Cheers for the help/advice though.

Much appreciated.

Tom
 
Have you checked whether you may have inadvertently set the 'Break on all Errors' setting in the VBA editor options ?
 
Have you checked whether you may have inadvertently set the 'Break on all Errors' setting in the VBA editor options ?
Hi.

Thanks for the reply.

This is and always has been, set for 'break on unhandled errors'.

Cheers
 
As already mentioned, the Access default is to allow special keys.
When that option is disabled, it is normally for security reasons. The breakpoint issue (now fixed) was an unintended side effect

After 43 posts, we need a way of getting past this point.
Excuse me for not spending time checking back over the entire thread but have you tried
1. Checking for phantom breakpoints
2. decompiling to remove any corrupted code
3. Importing all objects into a new database

If all the above have been tested and didn't help, then I suggest you make a cut down version removing all sensitive data and upload here for others to test

This was the answer it seems.

Seems obvious now I fully understand how version 2305 fixed special keys.

Thanks to all who contributed.
 

Users who are viewing this thread

Back
Top Bottom