Cannot read LOV: FRM 40502

You can see underlying ORA-xxxx error by using
Display Error. Display Error can be accessed from the default Oracle Forms Runform Help menu, or by pressing the <Display Error> key.

The error is table or view does not exist. The used tables have synonyms and the grantings are correct (through roles and grantings).

If the form works for some users (like a DBA or the schema owner) then there is obviously a synonym or grant problem.  If it returns this error regardless of the user, then it is an error in the select statement in the form definition, or someone dropped or renamed a table (or view) after the form was last re-compiled.

I suspect that is if the schema owner can run it, the grants may have to be explicit and not through a role.  This could be because you are using objects accessed from the Form.  

I've checked the grants and synonyms. They are all present and correct. Every used table is still present. A co-worker also checked it. Everybody has the same problem. Might this be a bug?

I've checked the grants and synonyms. They are all present and correct. Every used table is still present. A co-worker also checked it. Everybody has the same problem. Might this be a bug?

I've checked the grants and synonyms. They are all present and correct. Every used table is still present. A co-worker also checked it. Everybody has the same problem. Might this be a bug?

R_KLOOSTERMAN,
If I were you, I would cut the query of the Record Group from which the LOV is based, and paste the query in SQL*Plus and see if you would get the same error message.  You should be able to go from there.
Good luck

Helle FBI-Agent, I did this, but not in the environment where the problem occurs.

Meanwhile I discovered the following. Both users are granted for the used tables through roles. One of them also has direct grants on one of the used tables, which the other user doesn't have.

The first user does not have the problem.

The problem is solved. The role was not set. One person het direct grants for all tables, the other didn't.

The person was granted for the role, but the role was not set. So it was not what you suggested. None of the users was schema owner and all of them had the correct role. Some people also had explicit grants for all used tables and therefore did not experience the problem when the role was not set. Others did not have all explicit grants and therefore experienced the problem.

All the above suggestions I checked myself and therefore there is no "winner". The only thing I did not check, was wether the role was set. That is why I am still thinking how to close the question.

I don't see why you would need both explicit grants and a set role.

Your said:  "Some people also had explicit grants for all used tables and therefore did not experience the problem when the role was not set".

This makes sense since they have all of the grants.

Then you said:  "Others did not have all explicit grants and therefore experienced the problem".  [experienced the problem when the role was not set].

So did you grant the remainder of the grants, or simply set the role?  

If you granted the remainder of the grants, I may still be correct.  If you can revoke all the grants and it still works only with the role, then it was simply that the role was not set.

I don't think you need both a role and explicit grants, it should be one or another especially for the purposes of administering privileges and users.  (I have seen roles with no privileges that the form checks for access, however in this case the role wasn't more than a key word, that if granted would allow passage).

I decided to give all the people who cooperated 25 points:

Henka: https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=oracle&qid=20172834
Markqeer: https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=oracle&qid=20172835
FBIAGENT: https://www.experts-exchange.com/jsp/qManageQuestion.jsp?ta=oracle&qid=20172836

the explicit grants are obsolete. It was used in the past, but they are not yet revoked.

Since we don't work with explicit roles anymore, we set the role.