Why does this query throw ORA-00942 on 10g while it works on 11g?

问题

I execute this query without problem on my 11g installation :

SELECT
    PRODUCT_INFOS_idm.FIELD_VALUE "mother_id",
    PRODUCT_INFOS_ep.FIELD_VALUE "product_thickness",
    COIL_INFOS.TIME_STAMP,
    COIL_INFOS.IN_THICKNESS,
    COIL_INFOS.MEASURED_LENGTH,
    COIL_INFOS.MEASURED_WIDTH,
    COIL_INFOS.PARAM_SET_TOP_SIDE,
    COIL_INFOS.PARAM_SET_BOTTOM_SIDE
FROM
    COIL_INFOS
INNER JOIN
    PRODUCT_INFOS PRODUCT_INFOS_idm
    on PRODUCT_INFOS_idm.COIL_ID_SYSTEM=COIL_INFOS.COIL_ID_SYSTEM
    and PRODUCT_INFOS_idm.TIME_STAMP=COIL_INFOS.TIME_STAMP
    and PRODUCT_INFOS_idm.FIELD_NAME='ID bobina'
INNER JOIN  
    PRODUCT_INFOS PRODUCT_INFOS_ep
    on PRODUCT_INFOS_ep.COIL_ID_SYSTEM=COIL_INFOS.COIL_ID_SYSTEM
    and PRODUCT_INFOS_ep.TIME_STAMP=COIL_INFOS.TIME_STAMP
    and PRODUCT_INFOS_ep.FIELD_NAME='Anchura'
WHERE
    (COIL_INFOS.COIL_ID_SYSTEM LIKE '14051800' OR COIL_INFOS.COIL_ID LIKE '14051800')

But when my customer (who may have a 10g installation) executes it, he gets

ORA-00942: table or view does not exist

Other queries show that he has the same tables and columns. The following queries executes without problem :

select count(*) from COIL_INFOS
select count(*) from PRODUCT_INFOS

What can be the problem ? Is there a syntax error somewhere ? I suspect there is a problem with the Oracle version (I already had to remove the "as" I usually use for column aliasing). Does Oracle 10g support table aliasing ?

回答1:

There are several reasons why we might get ORA-00942.

The most obvious one is, the table does not exist in the database. That's easy enough to check in the data dictionary views, such as DBA_TABLES.
The table exists but we are referencing it wrongly. The common scenario is when the table was created with a mixed-case name in double quotes; when this happens we always have to refer to the table name with a mixed-case name in double quotes, because EMPLOYEES != "Employees".
The table is owned by a different user and our code doesn't include the schema name when we call it (and we don't have a synonym either).
The table is owned by a different user and that user hasn't granted us privileges on it.
The table is owned by a different user and that user has granted us privileges on it through a role but we want to reference it in a stored procedure or a view. In this situation we must have the privileges granted to our user directly, because the Oracle Security model works that way.

Given that you say "Other queries show that he has the same tables and columns" we can rule out the first option, and probably the second one. So it's most likely a problem with a missing synonym or missing permissions.

回答2:

As was hinted by Bob in comments, the problem was due to a bad version of Oracle 10g.

There are a few servers on which the same schema and the same query are used, only the one with version 10.2.0.1.0 had the problem. Oracle experts think the bug doesn't exist on 10.2.0.4 but I have no access to Oracle bug database.

As patching the server was out of question for our customer, we finally got around the bug by creating a view for this query.

TLDR : when Oracle says a version is buggy and should not be used, it should not be used.

回答3:

There's no problem with Oracle version. You are using standard queries that will work in even older version of Oracle than 10.

I suspect one or more of the following will be true:

you may have synonyms in your 11g database but not in 10g at the client.
The client is using different credentials to test select count(*) from table than that used to run the query.

来源：https://stackoverflow.com/questions/13029383/why-does-this-query-throw-ora-00942-on-10g-while-it-works-on-11g

标签

sql

Oracle

oracle10g

oracle11g