SELECT owner, table_name
FROM dba_tables
This is assuming that you have access to the DBA_TABLES
data dictionary view. If you do not have those privileges but need them, you can request that the DBA explicitly grants you privileges on that table, or, that the DBA grants you the SELECT ANY DICTIONARY
privilege or the SELECT_CATALOG_ROLE
role (either of which would allow you to query any data dictionary table). Of course, you may want to exclude certain schemas like SYS
and SYSTEM
which have large numbers of Oracle tables that you probably don't care about.
Alternatively, if you do not have access to DBA_TABLES
, you can see all the tables that your account has access to through the ALL_TABLES
view:
SELECT owner, table_name
FROM all_tables
Although, that may be a subset of the tables available in the database (ALL_TABLES
shows you the information for all the tables that your user has been granted access to).
If you are only concerned with the tables that you own, not those that you have access to, you could use USER_TABLES
:
SELECT table_name
FROM user_tables
Since USER_TABLES
only has information about the tables that you own, it does not have an OWNER
column – the owner, by definition, is you.
Oracle also has a number of legacy data dictionary views-- TAB
, DICT
, TABS
, and CAT
for example-- that could be used. In general, I would not suggest using these legacy views unless you absolutely need to backport your scripts to Oracle 6. Oracle has not changed these views in a long time so they often have problems with newer types of objects. For example, the TAB
and CAT
views both show information about tables that are in the user's recycle bin while the [DBA|ALL|USER]_TABLES
views all filter those out. CAT
also shows information about materialized view logs with a TABLE_TYPE
of "TABLE" which is unlikely to be what you really want. DICT
combines tables and synonyms and doesn't tell you who owns the object.
Alex Keh from Oracle in aug 2013 says:
Managed ODP.NET is released. It is currently part of the Oracle DB 12c
client. To use managed ODP.NET, you have to download and install the
DB client. From there, you can extract just the managed ODP.NET
assembly and setup files. These files are less than 10 MB and can be
deployed to any target machines.
Currently, we are packaging a stand alone managed ODP.NET release and
ODAC 12 release that will be much smaller. This will be released on
OTN shortly.
If you can wait a couple of days, ODAC 12c will be out on OTN and you can download that version. That will be our latest and greatest
managed ODP.NET version
====
We do not plan to put managed ODP.NET on NuGet. We believe that the
managed ODP.NET download with ODAC will provide the same benefits of
NuGet in terms of assembly isolation and download size.
There's a thread discussing whether Oracle should provide managed
ODP.NET NuGet support. Once you use ODAC 12c, I would like to know
your thoughts on whether NuGet support is still necessary.
https://forums.oracle.com/thread/2559445
Nuget managed ODP.NET:
PM> Install-Package Oracle.ManagedDataAccess
So what is the problem anyway?
Basically up until now, ODP.NET was a .NET layer that talks to the Oracle client .dll files, a small fact that had many implications:
- Large installation footprint (several hundreds of Mb)
- Tough deployment to remote machines - needs to install ODP.NET on client
machine or deploy large files
- Challenging when working with several versions, 32bit/64bit os and applications
So what is it?
The managed driver is basically a single .dll file with a .Net native implementation of ODP.NET.
That means no Oracle Client is needed, and now native code is behind the scenes. XCopy installation can be done easily.
Major benefits:
- Small footprint
- Compiled as any cpu so it can work on 32bit/64bit OS
and application smoothly. Easy to manage multiple versions on the
same machine
- Can be deployed as a simple reference in the application
bin directory.
So what's the catch?
- Not all features are supported (although most of them are... ) you
can find out more on the documentation
- Namespace is changed from
Oracle.DataAccess.Client to Oracle.ManagedDataAccess.Client
- Performance differences are still not clear. (The old) Native code
always perform very efficiently, but on the other hand 100% managed
code has it's performance benefits.
Please note that the Native-Code ODP.NET is still very much available. The managed version (at least for now) comes in addition to the native one.
References: http://oracleatdotnet.blogspot.com.es/2013/07/odpnet-managed-driver-beta-2.html
Differences between the ODP.NET Managed Driver and Unmanaged Driver
http://docs.oracle.com/html/E41125_02/intro004.htm
Features of Oracle Data Provider for .NET
http://docs.oracle.com/database/121/ODPNT/features.htm#ODPNT0007
Best Answer
Oracle XE is kinda special in that you typically install the server and client on the same machine. Logically, they are separate, but it does make things a bit harder to understand. For that reason, I will refer to other experts.
The folks at ORAFAQ have information about the TNSNAMES.ORA file. My personal strategy is to make all my TNSNAMES.ORA files the same, so there is no opportinity for confusion.
ODP.NET is for...
.NET
use, while ODAC is "native" (OLE) and provides more tools than you may have with just ODP.NET. Use whatever works for your needs.For most cases, you would distribute the Instant Client. The Full Client is more useful for developers. Refer to the documentation and FAQs for details. You can have multiple clients on one machine, so I'm not sure what the problem is.
Restart the machine? Did you add the appropriate library/libraries to your environment?