Ave !
If it's so, that user_a
like to use customer table and user_b customer_b
table with same
application, why You can't use synonyms? User_a synonyms
points to customer table
and user_b synonyms points customer_b table etc.
Or is there some decision
making before start using application: "Now I want
use customer table and now
I want user customer_b table"? If so, create two
database users, whose
synonyms points to different tables. When user logs in,
he selects appropriate
login username depends, which tables he wants to use.
Too simple :)
?
HTH
Jorma
-----Original Message-----
From: ext [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 16 July, 2003 07:29
To: Multiple recipients of list ORACLE-L
Subject: Re: Transparent database objects after merging
From: ext [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: 16 July, 2003 07:29
To: Multiple recipients of list ORACLE-L
Subject: Re: Transparent database objects after merging
Thank you for your idea, Mark,
To explain more about the problem
Before we have 2 databases which they both have same sturcture and same database objects names. We have 2 set of D2K forms and reports to access to each database.
After merging, we looking for move data from database B to database A but still be able to access by using the different of forms and reports. However the tables which be move from database B to datbase A, will be rename to <table>_B.
The developer just throw me a fire ball that what-if they don't modify the forms and reposts, is it possible to have one set of the forms access the <table>_B
UK
| "Mark Richard"
<[EMAIL PROTECTED]> Sent by: [EMAIL PROTECTED] 07/16/2003 12:14 PM | To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]> cc: Subject: Re: Transparent database objects after merging |
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).
