title: Unable to create a simple view on Oracle table
body: <p>An external DB admin guy exported a production database and imported it into test environment.  We are using Oracle 9.2.  Majority of imported database objects (tables, views, idexes, packages,...) works fine, but we have problems with three specific tables: we can do SELECT,UPDATE, DELETE on those tables, but we can not create views on this tables.</p>
  
  <p>In other words, the folowing works:</p>
  
  <pre><code> create or replace view v_test_view as select 1 x from dual; // we can create views
   create or replace view v_test_view  as select 1 x from someTable;
   select * from problematicTable; // we can select data from problematic table
  </code></pre>
  
  <p>But this does NOT work:</p>
  
  <pre><code> create or replace view v_test_view  as select 1 x from problematicTable;
  --&gt; ORA-01031: insufficient privileges
  </code></pre>
  
  <p>Background info:</p>
  
  <ul>
  <li>db admin used import/export utility  to copy the database schema</li>
  <li>the version of production and test Oracle are not exactly the same (production is 9.2.0.8, test is 9.2.0.7)</li>
  <li>after the initial import was done, the problematicTable was visible in object catalog (and database development tools), but when trying to SELECT from this table, we got back "invalid identifier". After that, the tables were re-imported and now we are able to SELECT from the, but not to create views on them </li>
  </ul>
  
  <p>Any ideas?</p>
  
  <p><strong>UPDATE:</strong>
  It looks like the situation is even more strange. When using one oracle session we can SELECT data from this table, in another Oracle session (<strong>using the same user to login!</strong>), we are getting "ORA-00904: invalid identifier"</p>
  
  <p><strong>UPDATE#2:</strong>
  The export data that was used to import from was sucesfully used to import data to another test environment (lets call it TEST1) which is located on the same instace of Oracle as the problematic one (TEST2). The difference beteween those two environments are that TEST1 uses the same user (schema name) as the production, but TEST2 uses another user (soo the objects were imported into another schema name). The problematicTables do not have any special security properties that are different from the tables that works OK. </p>
  
  <p>Matra</p>