Yes it was the discussion in the tech forum.
=20
1 the original database is running on nt everything hosted by nt. D1
2 D2 runns on nt but is hosted on Linux using SAMBA
3 Target is D3 all on Linux
I am exporting D1 the only populated database which will be imported to =
D2
=20
D1 is 9.2.0.4
D2 and D3 are 10g D2 is just a means of upgrading to 10g without =
impacting D1
Cannot upgrade D1 as it is required prod database - well hang on maybe =
we should=20
=20

This was the discussion during the tech forum session, wasn't it? Sorry =
for not responding earlier, I was at a customer's site today.

First let's try to reconstruct the path you're following right now, and =
define some constants to refer to during the rest of this thread:

The original database (I say: D1) is running on NT, with instance, =
executables and data sitting nicely together on NT.
You created a second database, named D2 for now. The instance of D2 runs =
on NT, the database resides on a Linux box, using CIFS (Samba) for the =
connectivity.
The final database (let's call it D3) will have it's instance on Linux, =
as well as the datafiles.
You want to export D2. Purpose is importing the exportfile in D3.

D1 is 9.2.0.4
D3 will probably be 10.2.0.3
What version is D2? Did you upgrade D1 to 10 on NT? Or is it just a =
9.2.0.4 copy on NT?

If it's 10g you don't need the export. You can transport the =
tablespaces. If it's 9i you don't need the copy. You can export from D1.

BTW, I don't know whether accessing databasefiles through CIFS (and the =
Samba implementation of it) is actually supposed to work. It's a long =
time ago I created a database on some Windows platform, and I never had =
database files accessed through a share. Maybe it is supported, but it =
is not unlikely that you have to take care of some special Samba =
configuration settings to run this. I'm not surprised if this causes =
your export to fail.

During the discussion we came up with some possible scenarios, IIRC:

1.
Upgrade D1 from 9i to 10g, on the NT box
Create a D3 (10g) on Linux
Use the 10g capabilities for cross platform transportable tablespaces to =
import the (upgraded) D1 tablespaces to D3

2.
Create D3 on Linux (10g)
Export D1, eventually in several parts. You can export the 'static' data =
(lookup tables, historical data) with some fine-grained export scripts, =
using the proper where clauses, and import this in D3
Finally, during some downtime, you export the rest of the data from D1, =
and import this in D3
This scenario requires no D2.

Where does this theoretical model meet your actual situation? If we =
know, we might be able to help you further.