Renaming the table is no big deal, oracle has worked hard to make this sort of task quick and easy:- select * from tbl_car; CAR_ID CAR_NAME CAR_DATE ---------- ------------------------- --------- 1 Ford Fiesta 08-OCT-14 2 Vauxhall Corsa 08-OCT-14 select * from ebt_car; CAR_ID CAR_NAME CAR_DATE ---------- ------------------------- --------- 1 Ford Fiesta 08-OCT-14 2 Vauxhall Corsa 08-OCT-14 COLUMN object_name FORMAT A20 COLUMN object_type FORMAT A20 COLUMN edition_name FORMAT A20 SELECT object_name, object_type, edition_name FROM user_objects ORDER BY object_name; OBJECT_NAME OBJECT_TYPE EDITION_NAME -------------------- -------------------- -------------------- EBT_CAR TABLE PK_EMP INDEX PROC_INSERTDATA PROCEDURE REL_V1 SEQ_TBLCAR SEQUENCE TBL_CAR VIEW REL_V1 SELECT object_name, object_type, edition_name FROM user_objects_ae ORDER BY object_name; OBJECT_NAME OBJECT_TYPE EDITION_NAME -------------------- -------------------- -------------------- EBT_CAR TABLE PK_EMP INDEX PROC_INSERTDATA PROCEDURE REL_V1 SEQ_TBLCAR SEQUENCE TBL_CAR VIEW REL_V1 As we can see there is no difference between the tables as we would expect as we have only been working within the rel_v1 edition.So now its time for our first change to the application.The view can only be a straight up query of the table, it is able to display a subset of the available columns and alias them to mimic a rename.

CREATE OR REPLACE PROCEDURE my_car.proc_insertdata (p_string IN tbl_car.car_name%TYPE) AS BEGIN INSERT INTO tbl_car (car_id, car_name, car_date, car_edition) VALUES (seq_tblcar.

NEXTVAL, p_string, sysdate, SYS_CONTEXT('USERENV', 'SESSION_EDITION_NAME')); COMMIT; END proc_insertdata; / SELECT * FROM tbl_car; CAR_ID CAR_NAME CAR_DATE CAR_EDITION ---------- ------------------------- --------- -------------------- 1 Ford Fiesta 08-OCT-14 2 Vauxhall Corsa 08-OCT-14 3 Peugeot 305 08-OCT-14 REL_V2 SELECT * FROM ebt_car; CAR_ID CAR_NAME CAR_DATE CAR_EDITION ---------- ------------------------- --------- -------------------- 1 Ford Fiesta 08-OCT-14 2 Vauxhall Corsa 08-OCT-14 3 Peugeot 305 08-OCT-14 REL_V2 select * from tbl_car; CAR_ID CAR_NAME CAR_DATE ---------- ------------------------- --------- 1 Ford Fiesta 08-OCT-14 2 Vauxhall Corsa 08-OCT-14 3 Peugeot 305 08-OCT-14 select * from ebt_car; CAR_ID CAR_NAME CAR_DATE CAR_EDITION ---------- ------------------------- --------- -------------------- 1 Ford Fiesta 08-OCT-14 2 Vauxhall Corsa 08-OCT-14 3 Peugeot 305 08-OCT-14 REL_V2 So in the editioning view we can see the additional row but the additional column data is still not visible to the user.

The first step is to login as sys and enable editions for the schema owner and then grant access to all available editions:- At this point i would also change the current edition at the database level to ensure that all edition based worked is recorded within the first user created edition. Now its time to prepare the application so that it is ready for editions which involves setting up the initial editioning_views. You could completely rewrite your application to point to the new editioning view instead of directly to the table, costly in both development time and risk, or you could rename the tables and create the editioning views with the name of the tables, no costly development work but downtime and probably lots of it!

In my experience the downtime is the preferred option of the vendor, the client doesn’t want any downtime so wants neither option!

What can I say about Oracle Edition Based Redefinition (EBR) apart from the fact its awesome, absolutely bloody awesome!

As I’m writing this I have just completed a 6 month piece of work to move a clients application to EBR – and the results are in they completed their first apps upgrade with 8 minutes of downtime, It should have been zero but there was an issue with the ALB which required a reboot to resolve.

The introduction of editioning view can be a bit of a problem when DML is applied to the base tables as columns may no longer exist, formats may have changed etc.

As such crossediton trigger must be used to transform the data so that it is in the correct format when coming from the parent edition to the child edition, while reverse crossedition triggers do the opposite transporting data entered into the child edition so that it is valid for the parent.

This means that multiple editions can be used simultaneously without causing logical corruption of the data in the base table.

Both crossedition and reverse crossedition triggers should be applied directly to editioning views, rather than the base tables, which allows triggers to be edition-specific.

The command to change the edition at the database level is:- CREATE TABLE tbl_car ( car_id NUMBER(5) NOT NULL, car_name VARCHAR2(25) NOT NULL, car_date DATE NOT NULL, CONSTRAINT pk_emp PRIMARY KEY (car_id)); CREATE SEQUENCE seq_tblcar; CREATE OR REPLACE PROCEDURE my_car.proc_insertdata (p_string IN tbl_car.car_name%TYPE) AS BEGIN INSERT INTO tbl_car (car_id, car_name, car_date) VALUES (seq_tblcar.