Having an issue for about 5 years now. Migrated over an Access Front End to 64bit Access. Ever since that switch, the ERL() function, which is deprecated, does not work reliably in runtime version of the software and has only a moderate success rate while in accdb mode during design. I found only one other mention of this issue on the web, and someone had the same issue while using excel (https://stackoverflow.com/questions/62942335/erl-function-not-working-in-64-bit-o365-excel-vba
), so it appears I am not crazy.
I don't believe this has anything to do with my code, I have redesigned my error handler dozens of times and tried every trick in my book and cannot induce ERL() to work reliably during runtime, it mostly returns 0, but sometimes returns an integer that in no way relates to a valid line number in the procedure the error occurred in.
At this point I am not optimistic there is a solution for ERL() under 64bit office. Maybe I'm missing something but if ERL() is deprecated and line numbers in all VBA code are now useless in 64 bit, how the heck can I hope to trap errors during use in a meaningful way without knowing the line it occurred on?
Does someone know some other way to return the location of the error? My error handler does include the module and procedure that produced the error, but when some procedures are 100's or 1000's of lines, that is only marginally useful.