We have a requirement to synchronise our Discover usernames, with our AD (Active Directory) usernames. This means that some Discoverer usernames will have to be created and their workbooks linked from their old username to their new username.
I read a post saying that all i needed to do was add an entry (the new username) into the EUL5_EUL_USERS table. When i do this and try log into Discoverer with the newly created user, I get the following error message.
"...Default or specified schema containing EUL tables is inaccessible..."
Any help on how to resolve this would be appreciated.
Not only would you have to add the new user but you have to do the following:
The first two you should be able to do yourself within the Discoverer Admin tool.
The third one will need an update script on the EUL5_DOCUMENTS table.In this table is a field called DOC_EU_ID. This is the field that determines the owner of the workbook. You would need to update this field with the EU_ID from the EUL5_EUL_USERS table for the new user.
The fourth item will need an update script on the EUL5_ACCESS_PRIVS table. This table contains metadata about which workbooks have been shared with other users. If you have never shared a workbook you will have a much easier time. However, if you have shared workbooks you will also need to update this table to change the shared_with user, the owning user and the last updated by user.
In EUL5_ACCESS_PRIVS the field AP_TYPE contains GD for a shared document and the following fields are key:
The fifth item on my list is scheduled workbooks. If you have any of these I would recommend canceling the old schedules and setting them up again. Trying to do updates to existing schedules would be a nightmare.
Warning: be very careful when making any SQL updates to EUL5 tables as doing so could mess up your EUL and invalidate your system. Just because I am telling you the names of the fields and tables does not mean I am sanctioning updating them. I have worked with Discoverer for 20 years and I know what I can and cannot update. I always take backups so that I can restore afterwards. I am also aware that I cannot ask Oracle Support to help me out if I mess things up so - be very, very careful. This is not for the feint of heart or novice administrator. I strongly recommend taking a backup of any table you are going to update, just in case, and then do any updates in a test environment first when no users are accessing the system. In other words don't jump right in and start making changes to your production EUL before you are certain what you intend doing will not break the integrity of the system.
Hope this helps