Table name issue accessing OATS schema using OBIEE

Question

We are attempting to integrate OATS 12.1 with OBIEE 11g for reporting purposes and encounter the following error when using the BI Administration tool to update a row count of a physical table or query using the Analysis tool against our target OATS schema. For example:
There was an error while updating row count for
"OTM.atg.com".."OTM"."View_Tests":
[nQSError: 17011] SQL statement execution failed.
[nQSError: 17001] Oracle Error code: 942, message: ORA-00942:
table or view does not exist
at OCI call OCIStmtExecute: select count(*) from
OTM.View_Tests
I tried this out with other tables such as "TO_TestCase"
The reason for this error seems to be that our target schema contains tables that have quotes in the name when the table was created, which I understands enforces the preservation of letter case-- i.e. "Mixed_Case" names. Since this is not "our own" application, we don't really have any control over how the schema is created or the table/views named. Interestingly enough, the table appears in the BI Administration with the expected table columns, but the querying for row count and data fails.
One way we've worked around this is to manually create a VIEW of the table of interest in the target schema using all capitals. This works, but seems unnecessarily messy, especially if we are interested in using a VIEW that is already created as part of the schema.
I also found the following various discussions about setting the NQSConfig.ini file on line, but changing the value and restarting the OBIEE server doesn't seem to make a difference.
# Case sensitivity should be set to match the remote
# target database.
CASE_SENSITIVE_CHARACTER_COMPARISON = ON;
Are there other ways to get OBIEE to recognize mixed-case table names?
Thanks!

Answer 1

Bad day for good code. Have yet to spot any posted today... Sadly, yours is just another ugly hack.
The appropriate method for using SQL*Plus substitution variables (in an automated fashion), is as command line parameters. Not as static/global variables defined by some other script ran prior.
So if a script is, for example, to create a schema, it should look something as follows:
-- usage: create-schema.sql <schema_name>
set verify off
set define on
create user &1 identified by .. default tablespace .. quota ... ;
grant ... to &1;
--eof
If script 1 wants to call it direct then:
-- script 1
@create-schema SCOTT
If script 2 want to call it using an existing variable:
-- script 2
@create-schema &SCHEMA
Please - when hacking in this fashion, make an attempt to understand why the hack is needed and how it works. (and yes, the majority of SQL*Plus scripts fall into the CLI hack category). There's nothing simple, beautiful, or elegant about SQL*Plus scripts and their mainframe roots.