Run-time error "438"

[allanc]

Hello Everyone!

I am getting this error whenever I update a field on a form without having the VBA editor opened. Once I have my VBA editor opened, the macro which gets triggered after updating the field works perfectly fine.

Any ideas what would cause this issue?

Thanks!

 

[theDBguy]

Hi. What is the error message for error 438?

 

[vba_php]

WITHOUT the VBA editor opened? you mean like as a separate window? that makes no sense. I've never heard of one occurance of this happening just based on if a window is open or not. surely something else must be going on that you're missing....438 is "object doesn't support this method or property".

guy, let me know if I'm invading on ur turf in anything I post.

 

[allanc]

Hi guys,

Thank you for your posts. I tried again this morning and everything is working. Not sure what happened.

 

[Deleted member 147267]

Pretty sure that even if you opened the editor first then on the form did whatever raised the issue you'd still raise the error. I'd say the editor isn't related at all - it's just opening because of your error break setting. Also, it is not uncommon for code to finish after an error is raised and give the impression that all is well. When you think of it, it's probably not otherwise you wouldn't raise the error. Having said that, there is one condition that can exist that might make that not true. That would be if the code you read has not been correctly compiled. It is possible that compiled code does not match what you read in the editor. That is one reason why a db is sometimes opened with the decompile switch.

 

[theDBguy]

Hi guys,

Thank you for your posts. I tried again this morning and everything is working. Not sure what happened.

Hi. Thanks for the update. Good luck with your project.

 

[allanc]

Pretty sure that even if you opened the editor first then on the form did whatever raised the issue you'd still raise the error. I'd say the editor isn't related at all - it's just opening because of your error break setting. Also, it is not uncommon for code to finish after an error is raised and give the impression that all is well. When you think of it, it's probably not otherwise you wouldn't raise the error. Having said that, there is one condition that can exist that might make that not true. That would be if the code you read has not been correctly compiled. It is possible that compiled code does not match what you read in the editor. That is one reason why a db is sometimes opened with the decompile switch.

Hi Micron,

I got the same run-time error today.

I think I found the problem after reading your post and yes, it was due to the codes not being correctly compiled. After running the compile under "Debug" and fixing the issue, everything is fine. I think if the VBA editor is closed, Access runs a check then fires the run-time error but when the VBA editor is open, it skips the check and executes the codes directly? - I may be wrong

Just wanted to update this thread hoping to eventually help someone who searches this topic in the future.

Thanks everyone!

 

[Deleted member 147267]

I think if the VBA editor is closed, Access runs a check then fires the run-time error but when the VBA editor is open, it skips the check and executes the codes directly?

I am 99.5687% sure that is not true. The editor is for writing, testing and compiling code. The only things that will occur regardless of whether or not it is open are compile or run time errors and code execution. Probably not related to your original issue but one other bugaboo that the editor can introduce is 'ghost breaks' which are breaks you've removed but seem to linger. Adding, saving, compiling then removing the line, saving and compiling usually gets rid of it. I'd say it's proof positive that the code you read is not always what has been compiled.