Re: ORA-942 when accessing table SAPUSER Error on WP

Hi Benhjamin, thanks!, SAP note 400241 resolve my problem, just this part:

General checks

• Check whether creating the OPS$ mechanism in accordance with to Note 50088 (WINDOWS) or Note 361641 (UNIX) solves the problem.

• The table SAPUSER must occur in the system only once and it must be assigned to the user OPS$<sid>ADM. Use the following query to check this:
  
  SELECT OWNER FROM DBA_TABLES WHERE TABLE_NAME = 'SAPUSER';
  
  If the system returns an owner <owner> other than OPS$<sid>ADM, you must delete the relevant SAPUSER tables:
  
  DROP TABLE "<owner>".SAPUSER;
  
  If the system does not return OPS$<sid>ADM, you must create the table SAPUSER as <sid>adm and enter the password:
  
  CREATE TABLE "OPS$<sid>ADM".SAPUSER
    (USERID VARCHAR2(256), PASSWD VARCHAR2(256));
  INSERT INTO "OPS$<sid>ADM".SAPUSER VALUES ('<sapowner>', '<password>');

• This section applies particularly to NT. However, if more than one OPS$ user is also used on UNIX, you must perform the checks there at the same time.
  
  On NT, the user sapservice<sid> must also be able to access the table SAPUSER. In order to avoid data-consistency problems, it does not make sense to create an additional SAPUSER table that has the same contents. Instead, you should specify a synonym. Use the following command to check whether a suitable synonym exists:
  
  SELECT OWNER, TABLE_OWNER, TABLE_NAME FROM DBA_SYNONYMS
    WHERE SYNONYM_NAME = 'SAPUSER';
  
  This call should return either OPS$SAPSERVICE<sid> or PUBLIC as the first value, followed by OPS$<sid>ADM and SAPUSER. If this is not the case, recreate the synonym after you have deleted it:
  
  If PUBLIC is returned as the first value:
  
  DROP PUBLIC SYNONYM SAPUSER;
  
  If another name <name> is returned as the first value:
  
  DROP SYNONYM "<name>".SAPUSER;
  
  You can now recreate the synonym (if possible, not PUBLIC):
  
  CREATE SYNONYM "OPS$SAPSERVICE<sid>".SAPUSER FOR
    "OPS$<sid>ADM".SAPUSER;
  
  To allow access to the synonym (or the associated table), you must execute a grant. Only the OPS$ user to whom the table belongs has authorization to do this (in this case, OPS$<sid>ADM). Therefore, you must logon using the relevant operating system user (<sid>adm) and execute the following lines:
  
  CONNECT /
  GRANT SELECT, UPDATE ON SAPUSER TO "OPS$SAPSERVICE<sid>";

• By default, R3trans uses SAPR3 as the database user. However, you can use the environment variable to specify another database user. This makes particular sense with R/3 6.x, if SAPR3 is replaced by SAP<sid>. In R/3 4.x or lower, if dbs_ora_schema is set to a value other than SAPR3, the connection fails since this user does not exist in the database or in the table SAPUSER. As a result, errors such as ORA-01403 or ORA-01017 occur. Up to and including 4.6D, dbs_ora_schema must not be set in any user environment.

ORA-01004: default username feature not supported; logon denied

The OPS$ mechanism is not activated in Oracle. To provide the general OPS$ connection option, proceed as follows:

• Set the following parameter:
  
  REMOTE_OS_AUTHENT = TRUE

           in init<sid>.ora.

• Restart the database.

On Windows, you must also set the parameter SQLNET.AUTHENTICATION_SERVICE = (NTS) in sqlnet.ora.ORA-01017: invalid username/password; logon denied

Message ORA-01017 may occur in step 1a), 1b), or 2). Depending on this, the problem can be solved as follows:

1a) Log entries:  Logon as OPS$ user to get <sapowner>'s password
                  Connecting as /@<sid> on connection 0 ...
                  *** ERROR => OCI-call 'olog' failed: rc = 1017
                  *** ERROR => CONNECT failed with sql error '1017'
If you intend to use the standard password for <sapowner> anyway, you can ignore the error message at this point, because the OPS$ mechanism is not required at all and the system connects successfully using <sapowner>/sap. However, note that that BR*TOOLS do require a working OPS$ mechanism when using DB13 to execute.
           Otherwise, you must ensure that an appropriate OPS$ user is set up. To do this, proceed as follows:

• Check whether the parameter
  
  os_authent_prefix = ops$
  
  is set correctly in init<sid>.ora. If you have to make any changes, restart the database afterwards.
• On Windows, ensure that the following parameter is set in sqlnet.ora:
  
  SQLNET.AUTHENTICATION_SERVICES = (NTS)
• Determine which operating system user <os_user> wants to create the connection. If this is a connection that was initiated from the R/3 System (for example, work process connection, DB13 actions), the system uses the user <sid>adm on UNIX and the user sapservice<sid> on NT. If you manually called the program that executes the connection, the user that you used is decisive. ...

I read and check step by step this note, later SAP is running! ....

Thank you! ....