I'm chasing a temp-table mismatched error where two different users using the same icon (same startup parameters, propath and etc.), one receives a temp-table error and the other does not.
Do you distribute r-code? If so maybe stale r-code?
You may be able to use the logging provided by the FileID logentrytype. It will show whether we opened the .p or .r.
A Process Monitor trace would also show which version of the file was read, and the directory where it was found.
-debugalert will show the stack of the procedures called when a temp-table mismatched error was raised. So you will know an exact location of the called procedure.
It's our development environment. The r-code folder is high up in the PROPATH. I just can't think of what else to check. Users are using the same icon pointed to the same set of folders and files.
I looked at the stack trace. The referenced program are coming from the r-code folder, so I'm wondering if it is one of those errors that happened somewhere else and the error is just the first chance it could display the message and not necessarily the exact location where the error occurred.
Are there mapped drives that could be user-specific? You could have Q:\foo in the propath that resolves to two different network paths for two different users, depending on how their Q: drives are mapped.
Also, as this is dev can we assume you aren't using -q? Otherwise, two sessions with the same parameters could have different code if they started some time apart and cached different versions of r-code.
Mapped drives are pushed from the server, so they're the same for all users.
> I looked at the stack trace. The referenced program are coming from the r-code folder,
Start a session with the -zr parameter (Ignore r-code files / forces session compile). Will it eliminate the error?
This problem might be related to Windows 10 Creator Update.
So far, this is what I found out;
When the program is compiled on Windows with the Creator Update (aka .NET Framework 4.7 update), all users with Creator update work fine, but those with no update get the error. The reverse is true. Not so sure why only that specific part of the application is displaying the odd behavior. It might be because of the PROTECTED modifier for one the temp-table definitions.
Does your application use OOABL and .NET classes? What version of OpenEdge are you using? There is a known bug that has a similar pattern (code only runs correctly on Creators Update if compiled on Creators Update). This bug only affects releases 11.5 and earlier. The bug doesn't exist in 11.6 and 11.7.
We are using OOABL and .NET classes. We're on version 11.6.2.008.
We are using OOABL and .NET classes. We're on version 11.6.2.008.
It must be a different, but possibly similar bug, since the bug I know about was fixed in 11.6.0.
By the way, your user has only 10 days to revert back to previous version of Windows if the Creator Update was applied to the machine.