Database diagram from Microsoft Access that is connected to Oracle via ODBC connection - oracle

I have Microsoft Access that is connected to an Oracle database via ODBC connection. In Access now I can access tables and data from Oracle.
How can I view/construct the data diagram from from within Access ? I don't have access to the Oracle database itself.
Many thanks.

You can certainly use the diagram tools in Access to layout and creating a relationships diagram in Access. However that diagram while “pretty” will of course NOT effect nor enforce nor change any of the attributes on the server side. In fact EVEN when using an Access front end linked to an access back end file, you are free to create the diagram in the front end, but you CAN NOT CHANGE the data structures nor set the relationships that exist.
Of course the above assumes you have FIRST linked all the tables you are going to work with from the Oracle database into Access. Once you have all the tables you plan to work with linked to the Access front end, the you can freely launch the relationships tool/window in Access and the proceeded to drop in the tables and draw relationships between the tables. Access will not automatic “pull in” the relationships in the front end and access will not draw the connecting relationships between the tables for you. However you can most certainly layout the tables, and draw relationship lines between those linked tables. As noted, any changes you make in this diagram will NOT be reflected in the back end database.
So while you are most free to draw and layout the tables, in access when using linked tables from an Access database, an SQL server database, or in this case an Oracle database, such relationships DESIGN changes in ALL CASES need to be made by the tools provided with the back end database system you have chosen to use Access with as the front end.
So to be clear, even with linked tables to an Access database, the use of the diagram tools in the front end will not make structure or relationship changes to the database. Of course with an Access database you would open up the back end database and then YES you can modify tables and modify relationships directly from the relationship window.
So when using linked tables, no data structure or relationships changes can or will occur to the back end database. However as noted you are most free to draw a “pretty” diagram with Access diagram tool and print it out when using an Oracle back end database. In effect the relationship tool in Access becomes a diagram tool without the ability to make changes to the linked database in question.

Related

Data area access through SQL

I am looking for advice on how to use the QSYS2.DATA_AREA_INFO in a particular situation. So I have created a few views which selects data from multiple tables. I am trying to fetch data from a data area as well using the DATA_AREA_INFO function.
The views need to be installed in a number of data libraries. The create view SQL statement does not have any libraries hardcoded. The tables to pull data from will be based on the default library we set in iSeries navigator while creating the views. So once the view is created, it would permanently point to tables from the default data library set. (Hope this is correct?)
The issue is with fetching the data from the data area:
SELECT DATA_AREA_VALUE
FROM TABLE(QSYS2.DATA_AREA_INFO(
DATA_AREA_NAME => 'TESTDA1',
DATA_AREA_LIBRARY => '*LIBL'))
Writing the statement as above would result in the view selecting the data from the data area present in the library list.
But the jobs from which the views will be executed might not have a library list setup. Hence I cant rely on DATA_AREA_LIBRARY => '*LIBL'
Is there a way I can make the view point to the same data library always (same as how the tables work)?
You could wrap up the data area access in a (service)program which accesses the *dtaara via ILE. The advantage is, that your able to reuse the program in several ways, in and outside an sql context. You can find information about this technique here:
Scott Klement Powerpoint

Suggestion on Reading a Oracle Data Model

Background:
I am doing a self study on an Oracle Product (Argus Safety Insight), and I need to understand the database schema of this product. I have installed the database and loaded the schema successfully. I have also generated data model using "SQL DEVELOPER DATA MODELER".
Issue:
This schema has 500 tables and 700 views which together gives around 20K columns, I couldn't navigate through the data model due its huge size; SQL developer hangs.
Question:
Will you please help me with a tool or technique on how to read and understand the logical relationships between tables in such huge databases.
You have two issues.
1: Technical - 'sql dev hangs' - you're asking it to open something so big, it overwhelms the Java Virtual Machine (JVM). For really LARGE models, we recommend you bump this to 2 or even 3 GB.
To increase the memory for the JVM, you need to find the product.conf file for SQL Developer. On Windows, it's under AppData for your user, and roaming profiles. On a Mac/NIX, it's in your $HOME directory, and then in a .SQLDev 'hidden' sub directory.
The file is documented quite well, but you need to do something like -
AddVMOption -Xmx2048m
Save, then re-open SQLDev and your design.
2: Human - how do you make sense of hundreds or thousands of objects in a diagram? You just can't. So you need to find application-driving MAIN tables, and generate SubViews (a subset of the diagram) for easier digestion.
I talk about how to do this here.
Now that your objects are grouped by SubViews, you can now view, print, report, and search them by SubView as well.

Oracle, Preventing access to ALL_*/USER_* views

I'm assuming that it CAN be done, I just don't know how or haven't been able to find a way to do it.
In Oracle, can access to the ALL_* tables and USER_* tables be revoked, including select grants.
For example, the all_objects, all_procedures views. Can access to these be restricted?
The same goes for user_tables and user_procedures and any other user_* views. Can access to them be restricted?
No, you can't (reasonably) prevent users from being able to query the ALL_* or USER_* views. You could go through and individually revoke access to each and every one of these views from PUBLIC but that would be a rather painful effort to go through, it would cause all sorts of applications to break not to mention breaking scripts from Oracle. You would end up, at a minimum, re-granting access to those views to any account that connected to the database because every database API interrogates the data dictionary views. Whether you have an ODBC application, a JDBC application, a PL/SQL IDE like TOAD or SQL Developer, or just about anything else, those applications will need to query the data dictionary.
The data that they will see in either view, however, will be limited to the objects that they have access to (for the ALL_* views) or the objects that they own (for the USER_* views). What purpose would be served by restricting a user's ability to query the data dictionary to determine what objects the user owns or what objects the user has access to? It would seem extremely odd to want a user to own a table but then to not allow the user to know that he owned that table.
Now, if you are really determined, you can create objects in the user's schema (tables or views) named, say, ALL_TABLES or USER_TABLES. Assuming that the user just queries ALL_TABLES rather than specifying a fully qualified SYS.ALL_TABLES, they will be querying the local object not the data dictionary view. That is generally a very inadvisable thing to do-- lots of products work by querying the data dictionary so causing the data dictionary queries to return the wrong set of data can lead to all sorts of bugs that are terribly hard to track down. But it is an option if you really, really want to restrict what data is returned from the data dictionary.

Retrieving tables from "Other users" in nHibernate

First of all I won't to say that I'm an expert in database handling, and less so in oracle. However right now I need to get better at it :)
I'm using nHibernate as orm, to my oracle database. It works ok, and is rather simple to use. However now I have run in to a problem that I don't know how to solve.
In the Database theres a kind of tree with the tables, views, indexes and such. At the end there are also a entry called "Other Users" in which there are some users with access to what I'm guessing is other tables. Now I would like to get data from one of those tables (I can read them manually in SQL Developer, so it's not a access problem or anything). Does anyone have any idea how I shall do that?
The account that you use in SQL Developer has at least read privilges to tables in another schema (owned by another user). You can access these tables by prefixing the table name with the schema name. In Hibernate you'll have to define the non-default-schema in the mapping.

Filter table list in MS-Access Link Table?

WinXP Pro
Oracle 10g Instant Client 10.2.0.1
MS Access 2003
When I link a table in MS Access, the pick list that appears shows me every table and view in the system I have access to. This list is quite large. Normally, I really only want to look at the tables that I own. Is there a way to filter the items displayed based on owner, or any other criteria?
Not really.
You could work around it by getting another account set up that just has access to your tables and link against them that way. When you are pleased as punch with the links you have created, you can always update the links (link to a new location, pointing at your account perhaps) in the Link Table Manager.
You could create a local table of the objects (tables and views) you 'own' in the distant database. You could then write some VBA code where, by looping on this table and using the doCmd.TransferDatabase method, you could automatically generate your links.
Yes, you can set a SCHEMALIST parameter within your ODBC connection (under the advanced settings tab) and specify the table schemas you want to include in your table link list. This will then bring back only the tables you listed in the SCHEMALIST.

Resources