Database Reference
In-Depth Information
following output is actually in octal (base 8), so the number 0000012 on the second line is in octal and represents
the decimal number 10. This tells us what byte in the file we are looking at. I've formatted the output to show ten
characters per line (using
-w10
), so 0, 12, 24, and 36 are really 0, 10, 20, and 30:
[tkyte@desktop tkyte]$ od -c -w10 -v demo.dat
0000000 1 0 , S a l e s , V
0000012 i r g i n i a , T h
0000024 i s i s t h e
0000036 S a l e s \n O f f i
0000050 c e i n V i r g
0000062 i n i a
0000074
0000106
0000120 2 0 , A c c o u n t
0000132 i n g , V i r g i n
0000144 i a , T h i s i s
0000156 t h e A c c o u
0000170 n t i n g \n O f f i
0000202 c e i n V i r g
0000214 i n i a
0000226
0000240 3 0 , C o n s u l t
0000252 i n g , V i r g i n
0000264 i a , T h i s i s
0000276 t h e C o n s u
0000310 l t i n g \n O f f i
0000322 c e i n V i r g
0000334 i n i a
0000346
0000360 4 0 , F i n a n c e
0000372 , V i r g i n i a ,
0000404 T h i s i s t h
0000416 e F i n a n c e \n
0000430 O f f i c e i n
0000442 V i r g i n i a
0000454
0000466
0000500
[tkyte@desktop tkyte]$
Notice that in this input file, the newlines (
\n
) are not there to indicate where the end of the record for SQLLDR
is; rather, they are just data to be loaded in this case. SQLLDR is using the
FIX
width of 80 bytes to figure out how
much data to read. In fact, if we look at the input data, the records for SQLLDR are not even terminated by
\n
in this
input file. The character right before department 20's record is a space, not a newline.
