Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> [IMP73] NT & UNIX

[IMP73] NT & UNIX

From: Norman Dunbar <Norman.Dunbar_at_lfs.co.uk>
Date: Fri, 26 Oct 2001 16:45:59 +0100
Message-ID: <E2F6A70FE45242488C865C3BC1245DA72316D4@lnewton.leeds.lfs.co.uk>


Hi Yann,

I'm just a little suspicious - Unix doesn't create zip files, bit it does produce .Z or .gz or .bz2 and .tar files. Zip files are a Windows speciality. Also, Unix exports with a CHR(10) as the end of line character, while NT uses CHR(10) + CHR(13). To be sure, I've just carried out an export on my HP-UX 10:20 server using Oracle 7.3.4 and dumped the resulting file (first 100 bytes) in character mode using xd, which gives the following :

srcdba_at_hp015> xd -tc -N 100 norm.dmp
0000000 003 \0 002 E X P O R T : V 0 7 . 0 3 0000010 . 0 4 \n D S Y S T E M \n R U S E 0000020 R S \n 1 0 2 4 \n 0 \n \0 (Invalid characters are shown in octal - 003 or 002 for example.)

The above shows linefeeds as '\n' (same as in C and C++). The above again in hex mode this time gives the following :

srcdba_at_hp015> xd -N 100 norm.dmp

0000000     0300    0245    5850    4f52    543a    5630    372e    3033
0000010     2e30    340a    4453    5953    5445    4d0a    5255    5345
0000020     5253     a31    3032    340a    300a      20    2020    2020
0000030     2020    2020    2020    2020    2020    2020    2020    2020

Which, hopefully, you can see that the '\n' characters are actually hex(0A) which is a single Unix linefeed. If your file shows Hex(0A) and HEX(0D) then the people who sent you the export file have indeed ftp'd it from a Unix server to an NT server in ASCII or TEXT mode and not in BINARY as required. Get them to do it again and correctly this time :o)

If you try to edit the file, you will probably find that you just corrupt it even more. Oracle stores some data (dates, numbers etc) as binary in the dump file. How do you know which ones should be a single CHR(10) and which are actually CHR(10) followed by CHR(13) (or the other way around). Best not to play with that dump I'm afraid - it is corrupt.

I get dump files from a Spanish customer, they used to export on an AIX Unix box, tar up the dump file, ftp it to an NT server, create a tape using NT Backup - well known broken software - and send it to me. I had to load it onto an NT server, restore it, ftp to a Unix server, untar and import - it would invariably fail with the same error as you are getting and they would admit to having ftp'd it in text mode.

Hope this helps.

Norman.



Norman Dunbar			EMail:	Norman.Dunbar_at_LFS.co.uk
Database/Unix administrator	Phone:	0113 289 6265
				Fax:	0113 289 3146
Lynx Financial Systems Ltd.	URL:	http://www.Lynx-FS.com

------------------------------------------------------------------------

Received on Fri Oct 26 2001 - 10:45:59 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US