I have come across this bug on the DF runtime, which is pretty hard to notice, to debug, and to trace back to its source. I'm pretty sure this is a clear case of UB in the runtime. In summary, DF cannot handle classes that are entirely unrelated having the same name for a given member function but different return types. This applies across your application, dependencies included. There's what appears to be a global scope function-name/return-type entanglement through the execution of your application.

To demonstrate:

Class cFoo is a cObject
    Function GetDummy Returns Handle
        Function_Return 10

Class cBar is a cObject
    Function GetDummy Returns String
        Function_Return "a"

Procedure TestDummyValue Variant vdummy

Handle hfoo hbar
Get Create (RefClass(cFoo)) to hfoo
Get Create (RefClass(cBar)) to hbar
Send TestDummyValue (GetDummy(hfoo))
Send TestDummyValue (GetDummy(hbar))
The code above reproduces in a constrained scenario this issue in a manner in which a runtime error is triggered. Unfortunately, this runtime bug is very unlikely to manifest this nicely on live codebases, and it silently causes code to behave in unexpected ways. I've seen cases in which a function would return a non-zero value, and yet the runtime would evaluate that as false. In other cases, a few calls would be OK due to implicit conversion hiding the issue all together.

This is a very insidious issue. Any codebase out there could start manifesting this sort of behaviour merely by updating a dependency, and code that you are not even aware of, starts interfering in the return types of your own functions and causing bizarre results.

DataAccess, can we please have a security update on this?