Mark Rittman's Oracle Weblog
This is the weblog for Mark Rittman, a developer working on Oracle Data Warehousing technology based in Brighton, England. You can contact me at mark@rittman.net.
        

13 July 2003

I just happened across an interesting thread on comp.databases.oracle.server about Discoverer EULs. The questioner asked:

"A little confused about Discoverer concepts.

I have a database with multiple schemas. There is a need for reporting (ad-hoc as well) against data in each of the schemas.

Given this background...

1) Do you create a single EUL for the whole database or is the EUL per
schema.
2) What are best practices when designing a Discoverer Environment
."

This is a question i'm often asked and there's no straight answer. Some of our clients set up one EUL for each instance, some create an EUL in each schema that is being queried.

Daniel Morgan responded first with the comment:

"There is no single correct answer. You create an EUL that best fits the needs of those doing the reports. If a single report crosses schemas ... cross schemas. If not ... don't."

This would seem to be sensible advice, and gives a clear reason why you might want to install just one EUL - because individual reports take data from a range of schemas.

Connell then followed on from this with some additional advice:

"I pretty much agree...it depends.

But in general, from an ease of maintenance point of view, I would usually advocate creating one EUL per instance.

Then I normally create a single Business Area called 'Administration' that holds all the objects that I need to write the reports.  Once you've built the complex folders etc that you need, create one Business Area for each logically related group of folders...so you might have 'Sales', 'HR' etc.
There is nothing to stop you from having the same folder in multiple business areas.

Then use the security/privileges to restrict user access to those Business Areas that they actually need - I don't normally let anyone see the Administration BA.
"

Sounds like good, practical advice. Thanks Connell.

Whilst trying to find out a bit more about Connell (to properly credit him for these comments) I came across another posting he made on converting a standalone Discoverer 4.1 EUL to an Oracle Apps EUL. The questioner asked:

"We have an EUL defined on our 8.0.5 database and use Discoverer 4.1 to access it.  We are considering moving it to another server and tying it into our Oracle Applications 11.03 system so we can better integrate the data.

I've been able to create an "apps only" EUL and can successfully connect with Discoverer 4.1 but now we would like to convert our "standalone" EUL over to an "apps" EUL that will properly access the application tables/views without losing our current definitions.

Has anyone actually done this?  Is it possible?  Any suggestions welcome
."

Connell's reply to this was:

"Steve,

Yes you can do this.

1. Take an EUL level export of all your business areas on the 8.0.5 DB
2. Create the APPS mode EUL
3. Grant Admin Privileges to an Apps user set up to maintain the Discoverer EUL.
4. From the admin edition, import the .eex file that was created in step 1.
5. Refresh the Business Areas and resolve any validation issues - you may find for example that you need to set up grants on certain objects in your EUL or that the Apps schema(s) don't contain the objects that the EUL was pointing to on the 8.0.5 Database.  Note that if the objects that were being referenced on the 8.0.5 Database don't exist in the apps DB then you'll obviously have lots of these issues!

That should be it pretty much, but as always test it a coupla times first!
"

Again, useful advice and in sufficient detail to act on it. Cheers Connell.


9:26:02 AM    

© Copyright 2003 Mark Rittman.
 
July 2003
Sun Mon Tue Wed Thu Fri Sat
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    
Jun   Aug






Click here to visit the Radio UserLand website.

Subscribe to "Mark Rittman's Oracle Weblog" in Radio UserLand.

Click to see the XML version of this web page.

Click here to send an email to the editor of this weblog.