Vercon & Permissions

I was pleased by the progress we made last week on Vercon. We ended our StaffDev by running into a little permissions issue. I am even MORE pleased with the progress we made today. Earlier today, John did some research and found a page with a possible solution.

We followed the advice of the solution that John found. However we ran into a new permissions issue. After a phone call and a new permission, I was able to create a view to a sys (oracle user) table. From there, I was able to grant view access to the Vercon program.

Today we also made sure that new owners (schemas) were being added automatically (daily – all with jobs). Also, we are auto-adding any objects of those owners.

Next we’ll use the owner backup option (locked=no backup, backup=backup, version control=15 different backups per object) and create backups of each object. Vercon doesn’t backup tables, only functions, procedures, packages, and package bodies.

The basic functionality of the program will backup all objects of all schemas (each night the job will run and will update any changed objects).

The next step will be to have a correctly functioning version control feature which will display the code from each version (allowing folks to copy the code into an editor and recompile it.

The final step would be to have a button next to each copy of the code, allowing the owner to ‘revert’ to a listed version of the code. It will also create a backup of the current code, allowing the owner to re-revert.

In some ways, I’ve complixified (new word) the tables required to hold code for PL/SQL. Oracle’s method basically uses only one table to hold all the code of all the objects. You could argue that it uses two – the second one holds dates like last update, etc… To do multiple backups (version control), I had to add a third table. I added the fourth table to allow for future modifiction, such that individual objects could be set to no_backup, backup, version_control, etc… This would allow someone to control backups at the object level vs. the schema (owner) level. We won’t implement that unless need be – but if we do we won’t have to alter the table design.

Leave a Reply