Relational database software generally permits multiple tables with the same name if they are:
- Owned by different users, or
- Placed in different databases (for RDBMSes which support multiple containers within an instance)
The usual way to distinguish which table is being referenced is by prefixing it with the owner name (and a period separator). The default behavior is to assume that a table without an owner prefix is owned by the current user, which is why you need to specify the owner of an other-owned table. Of course, security rules may prevent you from accessing tables owned by other users, so a "table does not exist" error may really be saying, "the table may exist, but if it does, you don't have SELECT access on it, so I'm not going to tell you about it."
Some databases (Oracle is one) support "public synonyms," which override the default naming by checking the list of synonyms before prepending the connected username. However, ArcGIS does not support synonyms, so this will not be part of an
It's best practice to always specify a table owner when scripting. ArcObjects provides helper functions to parse and qualify table and field references in an RDBMS-independent fashion. It's also advisable to avoid use of a data owner connection when testing, partially to detect incomplete table and field references, and partially to prevent data corruption during testing (a self-inflicted denial of service attack).
Recommended use of the SQL security model involves creating logins for each individual
who will connect to the database, "data owner" users to manage spatial datasets (the password(s) for which is closely held by the geodatabase administrator(s)), and database roles for each type of access to be granted to the users. If there is any unauthenticated access (as in a web application), then there should also be a user created for this as well (with a bare minimum of permissions). Then the necessary access to data tables can be granted to roles, and the roles granted to users (in a geodatabase, the GRANTs should be performed with ArcGIS tools, so ancillary tables all get the correct permissions). In this way, you can prevent situations where the "Bill" user owns core business data even though Bill moved on to a different job three years earlier. It takes a bit more work up front, but it makes for much less difficulty in maintenance later.