ADO/Oracle- how do I avoid using a table's schema name

Using VC++ 6 with ADO.

I'm new to Oracle, so this may be a setup issue. Currently I have to qualify a table name with it's schema name in order for even the simpliest of queries to work ( e.g. SELECT * FROM SHEMANAME.MyTable ). How can I avoid having to qualify a table with it's schema???

Logging in, I've tried both MS and Oracle OLE DB provider's; here are the connection strings:
1.) _bstr_t connectString = "Provider=OraOLEDB.Oracle;Data Source=Cardlist;User Id=MyUserName;Password=MyPassword;";
2.) _bstr_t connectString = "Provider=msdaora;Data Source=Cardlist;User Id=MyUserName;Password=MyPassword;";
3.) _bstr_t connectString = "Provider=OraOLEDB.Oracle;Data Source=Cardlist;OSAuthent=1;";

Thanks

You can use SYNONYMs (that was the solution adopted in a company were I was working, but maybe, there are other ways).

Here is an explanation about synonyms that I found at http://www.lsbu.ac.uk/oracle/oracle7.../SCN73/ch5.htm

Quote:

---

A synonym is an alias for any table, view, snapshot, sequence, procedure, function, or package. Because a synonym is simply an alias, it requires no storage other than its definition in the data dictionary.
Synonyms are often used for security and convenience. For example, they can do the following:

- mask the name and owner of an object
- provide location transparency for remote objects of a distributed database
- simplify SQL statements for database users

You can create both public and private synonyms. A public synonym is owned by the special user group named PUBLIC and every user in a database can access it. A private synonym is contained in the schema of a specific user who has control over its availability to others.
Synonyms are very useful in both distributed and non-distributed database environments because they hide the identity of the underlying object, including its location in a distributed system. This is advantageous because if the underlying object must be renamed or moved, only the synonym needs to be redefined and applications based on the synonym continue to function without modification.

Synonyms can also simplify SQL statements for users in a distributed database system. The following example shows how and why public synonyms are often created by a database administrator to hide the identity of a base table and reduce the complexity of SQL statements. Assume the following:

There is a table called SALES_DATA, contained in the schema owned by the user named JWARD.
The SELECT privilege for the SALES_DATA table is granted to PUBLIC.
At this point, you would have to query the table SALES_DATA with a SQL statement similar to the one below:

SELECT * FROM jward.sales_data;
Notice how you must include both the schema that contains the table along with the table name to perform the query.

Assume that the database administrator creates a public synonym with the following SQL statement:

CREATE PUBLIC SYNONYM sales FOR jward.sales_data;
After the public synonym is created, you can query the table SALES_DATA with a simple SQL statement:

SELECT * FROM sales;
Notice that the public synonym SALES hides the name of the table SALES_DATA and the name of the schema that contains the table.

---

Iteresting, I'm going to look into this now. Thanks for the tip.