The answer to 1) is absolutely yes. Here is an example showing that at work:

ops$tkyte@8i> drop table t;
Table dropped.

ops$tkyte@8i> create table t ( x int );
Table created.

ops$tkyte@8i> insert into t values ( 1 );
1 row created.

ops$tkyte@8i> commit;
Commit complete.



ops$tkyte@8i> host exp userid=/ tables=t

Export: Release 8.1.5.0.0 - Production on Tue Jun 13 07:09:23 2000
(c) Copyright 1999 Oracle Corporation. All rights reserved.
Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
Export done in US7ASCII character set and US7ASCII NCHAR character set

About to export specified tables via Conventional Path ...
. . exporting table T 1 rows exported
Export terminated successfully without warnings.

ops$tkyte@8i> host imp userid=/ full=y ignore=y

Import: Release 8.1.5.0.0 - Production on Tue Jun 13 07:09:25 2000

(c) Copyright 1999 Oracle Corporation. All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production

Export file created by EXPORT:V08.01.05 via conventional path
import done in US7ASCII character set and US7ASCII NCHAR character set
. importing OPS$TKYTE's objects into OPS$TKYTE
. . importing table "T" 1 rows imported
Import terminated successfully without warnings.

ops$tkyte@8i>
ops$tkyte@8i> select * from t;

X
----------
1
1


So, that shows that the table was appended to. As for 2, the answer is also yes (but we might need help). There are 3 cases to consider

- you've ADDED a column (no work on your part needed, we'll put a NULL in it)

- you've DROPPED a column (some work on your part)

- you've changed the datatype of a column.

Here is an example of each of the three. For the added_a_column case, we need do nothing. For the dropped and modified columns, we will import into a view with an instead of trigger that we use to perform whatever data remapping we need. In our case, we will just ignore the dropped column and we will convert a NUMBER into a DATE.

ops$tkyte@8i> create table added_a_column ( x int );
Table created.

ops$tkyte@8i> create table dropped_a_column ( x int, y int );
Table created.

ops$tkyte@8i> create table modified_a_column( x int, y int );
Table created.

ops$tkyte@8i> insert into added_a_column values ( 1 );
1 row created.

ops$tkyte@8i> insert into dropped_a_column values ( 1, 1 );
1 row created.

ops$tkyte@8i> insert into modified_a_column values ( 1, 1 );
1 row created.

ops$tkyte@8i> commit;
Commit complete.

ops$tkyte@8i> host exp userid=/ 'tables=(added_a_column,dropped_a_column,modified_a_column)'

Export: Release 8.1.5.0.0 - Production on Tue Jun 13 07:23:49 2000

(c) Copyright 1999 Oracle Corporation. All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production
Export done in US7ASCII character set and US7ASCII NCHAR character set

About to export specified tables via Conventional Path ...
. . exporting table ADDED_A_COLUMN 1 rows exported
. . exporting table DROPPED_A_COLUMN 1 rows exported
. . exporting table MODIFIED_A_COLUMN 1 rows exported
Export terminated successfully without warnings.

So, that constitutes our test case. We have exported the three tables "as is". Now, lets modify them:


ops$tkyte@8i> alter table added_a_column add ( y int );
Table altered.

ops$tkyte@8i> alter table dropped_a_column drop column y;
Table altered.

ops$tkyte@8i> delete from modified_a_column;
1 row deleted.

ops$tkyte@8i> alter table modified_a_column modify y date;
Table altered.


Now, if we attempt to import, we will find that "added_a_column" works OK but the rest fail


ops$tkyte@8i> host imp userid=/ full=y ignore=y

Import: Release 8.1.5.0.0 - Production on Tue Jun 13 07:23:49 2000

(c) Copyright 1999 Oracle Corporation. All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production

Export file created by EXPORT:V08.01.05 via conventional path
import done in US7ASCII character set and US7ASCII NCHAR character set
. importing OPS$TKYTE's objects into OPS$TKYTE
. . importing table "ADDED_A_COLUMN" 1 rows imported
. . importing table "DROPPED_A_COLUMN"
IMP-00058: ORACLE error 904 encountered
ORA-00904: invalid column name
. . importing table "MODIFIED_A_COLUMN"
IMP-00058: ORACLE error 932 encountered
ORA-00932: inconsistent datatypes
Import terminated successfully with warnings.


Ok, so now we have to put into the database views that look like the original tables. To accomplish this we will:

o rename the tables for a minute
o create a view that selects constants out of the right type -- eg: "select 1" for a number, "select sysdate" for a date, "select rpad( '*', 30, '*' )" for a varchar2(30) and so on
o create an instead of trigger that "does the right thing" for us, performing any data conversion/mapping we need


ops$tkyte@8i> rename modified_a_column to modified_a_column_TEMP;
Table renamed.

ops$tkyte@8i> create or replace view modified_a_column
2 as
3 select 1 x, 1 y from modified_a_column_TEMP;
View created.

ops$tkyte@8i> create or replace trigger modified_a_column_IOI
2 instead of insert on modified_a_column
3 begin
4 insert into modified_a_column_TEMP
5 ( x, y )
6 values
7 ( :new.x, sysdate+:new.y );
8 end;
9 /
Trigger created.

Here we are converting the number that was stored in Y into an offset from sysdate (why -- cause that was my "data mapping algorithm"). You would perform whatever conversion from string to date, date to number, number to string etc -- you wanted to here.

Now we take care of the dropped column:

ops$tkyte@8i> rename dropped_a_column to dropped_a_column_TEMP;
Table renamed.

ops$tkyte@8i> create or replace view dropped_a_column
2 as
3 select 1 x, 1 y from dropped_a_column_TEMP;
View created.

ops$tkyte@8i>
ops$tkyte@8i> create or replace trigger dropped_a_column_IOI
2 instead of insert on dropped_a_column
3 begin
4 insert into dropped_a_column_TEMP
5 ( x )
6 values
7 ( :new.x );
8 end;
9 /

Trigger created.


Here we are just getting rid of :new.y. We do not do anything with it -- just ignore it. It needs to be in the view so imp has something to insert into but we discard it in the trigger

Now we are ready to import again:

ops$tkyte@8i> host imp userid=/ full=y ignore=y

Import: Release 8.1.5.0.0 - Production on Tue Jun 13 07:23:50 2000

(c) Copyright 1999 Oracle Corporation. All rights reserved.


Connected to: Oracle8i Enterprise Edition Release 8.1.5.0.0 - Production
With the Partitioning and Java options
PL/SQL Release 8.1.5.0.0 - Production

Export file created by EXPORT:V08.01.05 via conventional path
import done in US7ASCII character set and US7ASCII NCHAR character set
. importing OPS$TKYTE's objects into OPS$TKYTE
. . importing table "ADDED_A_COLUMN" 1 rows imported
. . importing table "DROPPED_A_COLUMN" 1 rows imported
. . importing table "MODIFIED_A_COLUMN" 1 rows imported
Import terminated successfully without warnings.

Now the import runs cleanly... We need to go into the database and drop our views and rename our tables now:

ops$tkyte@8i> drop view modified_a_column;
View dropped.

ops$tkyte@8i> drop view dropped_a_column;
View dropped.

ops$tkyte@8i> rename dropped_a_column_TEMP to dropped_a_column;
Table renamed.

ops$tkyte@8i> rename modified_a_column_TEMP to modified_a_column;
Table renamed.


When we look at the data, we expect to see:

o 3 rows in added_a_column from the original insert and 2 imports
o 2 rows in dropped_a_column from the original insert and 1 import that worked on it
o 1 row in modified_a_column since we had to empty that table prior to altering the column type.


ops$tkyte@8i> select * from added_a_column;

X Y
---------- ----------
1
1
1

ops$tkyte@8i> select * from dropped_a_column;

X
----------
1
1

ops$tkyte@8i> select * from modified_a_column;

X Y
---------- ---------
1 14-JUN-00

ops$tkyte@8i>