Is there logging that I can turn on to see if there are prog

Posted by jquerijero on 14-Jun-2017 14:06

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.

All Replies

Posted by Roger Blanchard on 14-Jun-2017 14:22

Do you distribute r-code? If so maybe stale r-code?

Posted by Fernando Souza on 14-Jun-2017 14:28

You may be able to use the logging provided by the FileID logentrytype. It will show whether we opened the .p or .r.

Posted by Rob Fitzpatrick on 14-Jun-2017 14:32

A Process Monitor trace would also show which version of the file was read, and the directory where it was found.

Posted by George Potemkin on 14-Jun-2017 14:42

-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.

Posted by jquerijero on 14-Jun-2017 15:01

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.

Posted by jquerijero on 14-Jun-2017 15:05

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.

Posted by Rob Fitzpatrick on 14-Jun-2017 15:07

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.

Posted by jquerijero on 14-Jun-2017 15:38

Mapped drives are pushed from the server, so they're the same for all users.

Posted by George Potemkin on 15-Jun-2017 00:02

> 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?

Posted by jquerijero on 15-Jun-2017 10:43

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.

Posted by Matt Gilarde on 15-Jun-2017 11:18

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.

Posted by jquerijero on 15-Jun-2017 11:32

We are using OOABL and .NET classes. We're on  version 11.6.2.008.

Posted by jquerijero on 15-Jun-2017 11:33

We are using OOABL and .NET classes. We're on version 11.6.2.008.

Posted by Matt Gilarde on 15-Jun-2017 11:37

It must be a different, but possibly similar bug, since the bug I know about was fixed in 11.6.0.

Posted by jquerijero on 15-Jun-2017 15:51

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.

This thread is closed