Also, depending on your requirements (which I don't fully understand)
another approach may involve using views:

The CUSTOMERS view could point to either CUSTOMERS_A, CUSTOMERS_B or even
the merge of both tables (select * from customers_a union all select * from
customers_b) if required.  Of course you may introduce primary and foreign
key problems, but like I said - I don't fully understand your requirement
so I'm just throwing ideas up in the air.

Regards,
      Mark.



                                                                                       
                                               
                      "Arup Nanda"                                                     
                                               
                      <[EMAIL PROTECTED]        To:       Multiple recipients of list 
ORACLE-L <[EMAIL PROTECTED]>                  
                      om>                      cc:                                     
                                               
                      Sent by:                 Subject:  Re: Transparent database 
objects after merging                               
                      [EMAIL PROTECTED]                                                
                                               
                      .com                                                             
                                               
                                                                                       
                                               
                                                                                       
                                               
                      16/07/2003 13:59                                                 
                                               
                      Please respond to                                                
                                               
                      ORACLE-L                                                         
                                               
                                                                                       
                                               
                                                                                       
                                               




You can drop or rename CUSTOMERS to, say, CUSTOMERS_A, and then create
synonym CUSTOMERS pointing to CUSTOMERS_B. Or rename CUSTOMERS_B to
CUSTOMERS.

HTH.

Arup Nanda
 ----- Original Message -----
 From: [EMAIL PROTECTED]
 To: Multiple recipients of list ORACLE-L
 Sent: Tuesday, July 15, 2003 11:29 PM
 Subject: Transparent database objects after merging


 Hello Gurus,
         I'm working merging 2 databases which have sane structure of
 database objects into one database. However, after merging, the business
 policies and regulations force us to have 2 set of database objects; for
 example :
 Database A has CUSTOMERS table.
 Database B has CUSTOMERS table.

 After merging database A will have CUSTOMERS and CUSTOMERS_B (data from
 database B). I just wonder that is there any way that we don't need to
 change our script in forms and reports to point into a new table name but
 still can access to the data in the new table ( CUSTOMERS_B) not
 CUSTOMERS.
 Thank you for any comment and suggestion.
 Ukrit K,



<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
   Privileged/Confidential information may be contained in this message.
          If you are not the addressee indicated in this message
       (or responsible for delivery of the message to such person),
            you may not copy or deliver this message to anyone.
In such case, you should destroy this message and kindly notify the sender
           by reply e-mail or by telephone on (61 3) 9612-6999.
   Please advise immediately if you or your employer does not consent to
                Internet e-mail for messages of this kind.
        Opinions, conclusions and other information in this message
              that do not relate to the official business of
                         Transurban City Link Ltd
         shall be understood as neither given nor endorsed by it.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>




<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Privileged/Confidential information may be contained in this message.
If you are not the addressee indicated in this message (or responsible for delivery of 
the message to such person), you may not copy or deliver this message to anyone.
In such a case, you should destroy this message and kindly notify the sender by reply 
e-mail or by telephone on (03) 9612-6999 or (61) 3 9612-6999.
Please advise immediately if you or your employer does not consent to Internet e-mail 
for messages of this kind.
Opinions, conclusions and other information in this message that do not relate to the 
official business of Transurban Infrastructure Developments Limited and CityLink 
Melbourne Limited shall be understood as neither given nor endorsed by them.
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<---->>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Mark Richard
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to