Re: Very URGENT! Tablespace Extent Problem w/ Import

[Quoted] [Quoted] All I can say is you've been bloody lucky: it's not a text file (and there [Quoted] wouldn't be a log option or an indexfile option if it were).

But clearly, there's a risk I'm just being a bit of an old woman on this one... so I've just tested it. Export database...drop EMP....import EMP... success.

[Quoted] [Quoted] Make one change to the dump file (in this case, change EMP's Initial Extent [Quoted] [Quoted] from 64K to 32K) in notepad, and save. Drop EMP....import EMP.... import [Quoted] bombs out with complaints about the character set used in the dump file.

Er, did I back up the original dump file... did I buggery... I am now EMP-less!! Cheers, Dave! (OK, I admit, it wasn't your fault).

This is boring Windows 2000, and ye veritable notepad, 8.1.6. But I think [Quoted] my point is that (1) this is not recommended by Oracle (2) it's strongly dis-recommended by Oracle (3) it's stuffed up 100% of the times I've ever [Quoted] attempted it (not just this little test) and (4) it's not the kind of thing [Quoted] I'd recommend to newbies or the desperate.

HJR [Quoted] "Dave Haas" <davehaas_at_hotmail.com> wrote in message news:94j0h1$3vf$1_at_news3.cadvision.com...
> Hi Howard.
>
> I have edited MANY dump files with text editors (both Unix & NT) and have
> never had a problem. Granted the 'create table first' solution was
 probably
> better, but for small changes it sometimes seems easier to just edit the
> dump file.
>
> I was also trying to explain the problem a little bit :)
>
> Regards,
>
> Dave Haas
>
>
> "Howard J. Rogers" <howardjr_at_www.com> wrote in message
> news:3a6cfe7c_at_news.iprimus.com.au...
> >
> > "Knut Talman" <knut_at_mytoys.de> wrote in message
> > news:3A6CFAF3.DD57AA42_at_mytoys.de...
> > > > Dave, have you ever edited an expdat.dmp file, and then proceeded to
 import
> > > > successfully? I only ask because the data that is inserted by all
 those
> > > > "insert into" statements is binary encoded, and text-editing the
 dump
 file
> > > > is almost guaranteed to stuff that encoding up (and hence lose your
 data).
> > > >
> > > > The dump file most certainly isn't a text file, and should never be
 treated
> > > > as such. I guess you might get away with it once in a while, but I
 wouldn't
> > > > bet on it as a long-termer.
> > >
> > > If I may answer: I edited the dump files with a hex editor
> > > (khexedit) and wrote it back. I did not change the length of
> > > the file, just replaced the numbers in the STORAGE clause with
> > > my numbers. Until now there is no error from IMPORT (it is
> > > still running).
> > > BTW, my Linux workstation could not edit the file due to a lack
> > > of memory, so I did it on the server.
> > >
> > > Cheers,
> > >
> > > Knut
> >
> > No, that's fair enough... the fact you used a HEX editor is the thing,
> > confirming that the dump file really is a binary encoded file, not a
 text
> > one. I have students open the thing up in vi, trying to change the
> > tablespaces in which tables are stored for example, and then wonder why
 the
> > import spits the dummy -after all, you *can* see most of its contents in
 vi
> > (or notepad, come to that).
> >
> > Fingers crossed, eh?
> >
> > 5am????? Are you mad??!
> >
> > Regards
> > HJR
> >
> >
> >
> >
> >
>
>
Received on Tue Jan 23 2001 - 05:35:14 CET