Oracle 10g. Create alias for schema while import data

Question

I have a prod box with Oracle 11 and a schema, named A. For testing purposes, I need a local snapshot of prod data. The data is not very big, so export is not a problem. I've exported A into a bundle of SQL files (with DBeaver), one per table with contents like this:

INSERT INTO A.TABLE1 (F1, F2, F3) VALUES ('v11', 'v21', 'v31');
INSERT INTO A.TABLE1 (F1, F2, F3) VALUES ('v12', 'v22', 'v32');

and so on. The problem is that for development purpose I use schema named B, so while doing import I need inserts like this:

INSERT INTO B.TABLE1 (F1, F2, F3) VALUES ('v11', 'v21', 'v31');
INSERT INTO B.TABLE1 (F1, F2, F3) VALUES ('v12', 'v22', 'v32');

I know that I can find and replace all INSERT INTO A. with INSERT INTO B. and this will solve my problem, but maybe I can create some kind of an alias for schema B so I can do like this (pseudocode):

CREATE ALIAS 'A' FOR SCHEMA 'B'
@TABLE1.sql
@TABLE2.sql
DELETE ALIAS 'A'

Answer 1

Write your script without the schema names entirely. Or, edit the schema names out of it if it was generated by some silly tool :)

In your driver script, run ALTER SESSION SET CURRENT_SCHEMA x before calling the insert script.

Answer 2

You can't create an alias that maps one schema to another.

• You could potentially cause the tool that is generating the scripts to omit the schema name entirely. Then you could run the INSERT statements in whatever schema you would like
• You could use a different tool. The Oracle export and import utilities (classic or DataPump), for example, have parameters that let you map from one schema to another.

I would strongly question the wisdom, however, of developing using a schema name that is different from what it will be in production. That greatly increases the complexity of doing things like promoting code. Someone (or some tool) will inadvertently add a schema prefix to a table name in a query. You'll have to manually edit the scripts before promoting them from one environment to another and someone will eventually make a mistake and change the functionality of the code during the promotion process.