Runtime errors after office 365 version update (1 Viewer)

[tommyboy]

Suddenly getting some runtimes errors on a couple of access applications that have been in use for a long time with no issue.

They have only started appearing after updating to office 365 Version 2305 (Build 16501.20196) from Version 2304 (Build 16327.20248)

Runtime error 94 and 3024. The errors themselves are irrelevant and can just be ignored, but curious what has changed in the update for them to start popping up after years of using this particular program (the code has not changed).

Went back to the older version and low and behold, no runtime error messages.

Any ideas?

Thanks

 

[MajP]

You sure? This is the most common error for people to say "my code suddenly stopped working". That is not the case. What happened was that all previous data did not include Null values somewhere in the record and now you have records with null. Make sure any code that could fail due to a NULL handles a null

ex

dim x as long
x = SomeControl.value

to

x = nz(someControle.value, 0)

or

dim x as string
x = left(somecontrol.value, 3)

to

x = left(somecontrol.value & "", 3)

 

[tommyboy]

You sure? This is the most common error for people to say "my code suddenly stopped working". That is not the case. What happened was that all previous data did not include Null values somewhere in the record and now you have records with null. Make sure any code that could fail due to a NULL handles a null

ex

dim x as long
x = SomeControl.value

to

x = nz(someControle.value, 0)

or

dim x as string
x = left(somecontrol.value, 3)

to

x = left(somecontrol.value & "", 3)

Yeah, I can do the exact same thing in the old build and the error is not flagged.

The 94 runtime error occurs when leaving a space to start a field and then leaving the rest blank and exiting the field. But only occurs in the new build version, as I tested it to see!!

 

[The_Doc_Man]

The bugaboo is Office 365 build 2305.

Access Releases 14 Issue Fixes in Version 2305 (Released June 1st, 2023)

Our newest round of Access bug fixes was released on June 1st, 2023. In this blog post, we highlight some of the fixed issues that our Access engineers..

techcommunity.microsoft.com

Take a quick look. You will see that build 2305 has not been kind to Access.

 

[isladogs]

As error 94 is 'invalid use of null' and 3024 is 'cannot find file', I'd say the error numbers are relevant and cannot be ignored.
Having said that, I can't replicate your errors using the method described
Suggest you check your field properties e.g do you allow ZLS? Is required set to Yes?

As for v2305, there were a lot of useful bug fixes but unfortunately a few new issues were triggered by some of those fixes.
However, I've heard no other reports of the issues you describe.

 

[tommyboy]

As error 94 is 'invalid use of null' and 3024 is 'cannot find file', I'd say the error numbers are relevant and cannot be ignored.
Having said that, I can't replicate your errors using the method described
Suggest you check your field properties e.g do you allow ZLS? Is required set to Yes?

As for v2305, there were a lot of useful bug fixes but unfortunately a few new issues were triggered by some of those fixes.
However, I've heard no other reports of the issues you describe.

It was in this bit of code that produced the 94 error, but only on the new build. Does not occur on the old built, or any previous version...

Dim holder As String
Dim n As Integer
Dim length As Integer
Dim temp As String

holder = Me![Dam]
If holder Like "*(*" Then
length = Len(holder)
temp = ""
For n = 1 To length
If MID(holder, n, 1) = "(" Then
n = length
Else
temp = temp + MID(holder, n, 1)
End If
Next
holder = temp
Me![Dam Ref] = Trim(holder)
Else
Me![Dam Ref] = Me![Dam]
End If

If IsNull(DamYOB) = False Then
Breeder.SetFocus
End If

End Sub

 

[The_Doc_Man]

When showing code that produces an error, it very often helps to identify the line that actually throws the error. Which you would find if you took the DEBUG option (if it is presented).

 

[MajP]

As I said this code fails when Dam is null. Not sure what the confusion is.

holder = Me![Dam] & ""
or
holder = nz(me!Dam,"")

 

[tommyboy]

As I said this code fails when Dam is null. Not sure what the confusion is.

holder = Me![Dam] & ""
or
holder = nz(me!Dam,"")

It can be NULL

It often is in fact.

 

[MajP]

The point is not that this fails now the point is that it was allowed to ever work. What has changed is @isladogs stated. It is the property to allow ZLS. If this is set to false then a space bar results in a null, as I said YOU NEED TO TEST FOR!

AllowZeroLength	Required	User's Action	Value Stored
No	No	Presses ENTER Presses SPACEBAR Enters a zero-length string	Null Null (not allowed)
Yes	No	Presses ENTER Presses SPACEBAR Enters a zero-length string	Null Null Zero-length string
No	Yes	Presses ENTER Presses SPACEBAR Enters a zero-length string	(not allowed) (not allowed) (not allowed)
Yes	Yes	Presses ENTER Presses SPACEBAR Enters a zero-length string	(not allowed) Zero-length string Zero-length string

Only way to get a ZLS from a space is to set required to True and allow ZLS to true.

 

[tommyboy]

The point is not that this fails now the point is that it was allowed to ever work. What has changed is @isladogs stated. It is the property to allow ZLS. If this is set to false then a space bar results in a null, as I said YOU NEED TO TEST FOR!

AllowZeroLength	Required	User's Action	Value Stored
No	No	Presses ENTER Presses SPACEBAR Enters a zero-length string	Null Null (not allowed)
Yes	No	Presses ENTER Presses SPACEBAR Enters a zero-length string	Null Null Zero-length string
No	Yes	Presses ENTER Presses SPACEBAR Enters a zero-length string	(not allowed) (not allowed) (not allowed)
Yes	Yes	Presses ENTER Presses SPACEBAR Enters a zero-length string	(not allowed) Zero-length string Zero-length string

Oh right, so you are saying it should always have failed, but was just being missed before?

 

[MajP]

I do not know, why anyone would allow that. But personally I would think it is a stupid design to allow a space bar to create a ZLS, but that is up to you. Your settings have obviously changed. IMO for the better.

 

[MajP]

Either way you have two choices. Either write your code well so that it handles potential errors such as entered null values, or add error handler. The prior is preferred.

 

[tommyboy]

Either way you have two choices. Either write your code well so that it handles potential errors such as entered null values, or add error handler. The prior is preferred.

I did not write it at all!!

I am not an access expert, I just understand a few basics.

I have inherited an old group of programs that have worked perfectly for years and so I was curious as to why these runtime errors were suddenly being generated and I know my way around the backends to investigate a bit.

No contact with the original developer these days, so I have to try and troubleshoot anything myself for as long as i can.

 

[tommyboy]

It is interesting that the 3024 runtime error also should in theory always have been triggered, as the file name created by the code in question is not and has never been valid (it does not need to be, but that is by the by).

Yet, it was never flagged in a decade until this latest build. Wonder why it was letting it slide before?

Confusing!?

 

[shanegroff]

I'm a bit confused here. You say the error occurs on these lines:

holder = Me![Dam] & ""
or
holder = nz(me! Dam,"")

but neither of those lines appears in the code sample you provided.

If I have this code:
Dim holder as String
holder = Me![Dam]

Which does appear in the code you provided, then that will fail with Error 94 if Me!Dam is Null, but as far as I can tell, that would fail in earlier versions as well. (I didn't have a V2304 build handy, but I tried in V2302, and it gives an error there)

So, what code exactly is it that produces an error in V2305, but not in V2304? (or are you saying holder = Me![Dam] didn't give an error in 2304 when Me![Dam] is Null?)

Shane

 

[MajP]

Again, the reason it did not fail was because the original settings were Yes and Yes where a spacebar creates a ZLS not a null. The settings likely changed and now you are creating a Null with a spacebar

 

[tommyboy]

Again, the reason it did not fail was because the original settings were Yes and Yes where a spacebar creates a ZLS not a null. The settings likely changed and now you are creating a Null with a spacebar

The original settings in the table design view, were 'Required' - No and 'Allow zero length' - No

Have never been changed and never caused a problem with the runtime error until the latest update.

I have gone back to the old version now and all is fine again.

 

[tommyboy]

I'm a bit confused here. You say the error occurs on these lines:

holder = Me![Dam] & ""
or
holder = nz(me! Dam,"")

but neither of those lines appears in the code sample you provided.

If I have this code:
Dim holder as String
holder = Me![Dam]

Which does appear in the code you provided, then that will fail with Error 94 if Me!Dam is Null, but as far as I can tell, that would fail in earlier versions as well. (I didn't have a V2304 build handy, but I tried in V2302, and it gives an error there)

So, what code exactly is it that produces an error in V2305, but not in V2304? (or are you saying holder = Me![Dam] didn't give an error in 2304 when Me![Dam] is Null?)

Shane

holder = Me![Dam]

This is the line that generates the error.

I currently have two builds running side by side on different machines.

On 2304 - 16327.20248, this does not happen.

On 2306 - 16529.20064 this does happen.

Nothing else has changed.

 

[NauticalGent]

I am working with Build 16.0.16227.20202 (64 bit) and now some of my SELECT DISTINCT queries are thowing a "data mis-match" error. Took me a while to figure it out but I was able to find a work-around.

Gotta LOVE MicroSoft.