sqlldr not recognizing a file without an extension on Solaris
z1hou1
I am running a sqlldr command line on Solaris and the data file that I
need to load WILL not have an extension. On DOS/Windows, that is not
an issue since I can simply append a "." to the file name and sqlldr
recognizes it. On Solaris/Unix, it expects a file with the explicit
"." at the end of the file name.
So if the data file name is accountInputFile (note no dot or
extension), sqlldr responds by saying that the file name it expects is
accountInputFile.dat if I do not specify anything other than
data=accountInputFile.
If I do specify data=accountInputFile. as in windows/dos for a similar
situation, sqlldr attempts to find a file called "accountInputFile."
with the explicit "." at the end of the file.!
In short, on Solaris, there is, for me, no way of making sqlldr load a
data file with no extension and no "." (dot).
Can someone help me please?
Terry Dykstra
news:48509797-3442-4797...@c10g2000vbr.googlegroups.com...
put double quotes around the filename
--
Terry Dykstra
z1hou1
SQL*Loader-500 error, File not found and cannot find filename.dat
If I enclose it within quotes (single or double) and also put a "." at
the end of it, it goes back to the original post, sqlldr expects an
explicit filename with a "." at the end of it resident.
.
What is puzzling is this. The ls command recognizes the file without
any wildcard characters. The unix version of sqlldr is doing something
else with the parsing.
.
Regards,
z1hou1
John Hurley
snip
It is always helpful in posts like this to specify what version of
oracle you are using and what version of an operating system, etc.
Depending on oracle version there are some potential other ways than
sqlldr to get data loaded from an os file.
The easy solution is to rename and/or copy the input file to include
a .dat suffix ...
z1hou1
Oracle version 10.2.0.4
Solaris 8
At the moment, the file is presented the way it is and I would like to
explore the possibility that sqlldr can recognize a file without a "."
or an extension. If there is absolutely no way that sqlldr cannot
recognize a file with an extension, or ends with a ".", I will
certainly rename the file before processing again st sqlldr.
Regards,
z1hou1
John Hurley
snip
> Versions of db and o/s
With oracle 10.2 available you can treat the file as an external table
and get the contents into the database.
Kinda/sorta like sqlldr ...
ddf
From the Oracle 10.2 release documentation:
"Examples of INFILE Syntax
The following list shows different ways you can specify INFILE syntax:
Data contained in the control file itself:
INFILE *
Data contained in a file named sample with a default extension
of .dat:
INFILE sample
Data contained in a file named datafile.dat with a full path
specified:
INFILE 'c:/topdir/subdir/datafile.dat' "
Notice that Oracle specifies SQL*Loader looks for data files with a
default extension of .dat; also note that Oracle on Windows can
exhibit behaviour outside of the norm due to the differences between
how Windows 'works ' and how other operating systems function.
What prevents you from writing a shell script to do the following:
1) Temporarily rename the file with a .dat extension
2) Invoke SQL*Loader
3) Rename the file back to its original name
David Fitzjarrell
Tony Sequeira
[...]
>
> What prevents you from writing a shell script to do the following:
>
> 1) Temporarily rename the file with a .dat extension
> 2) Invoke SQL*Loader
> 3) Rename the file back to its original name
>
>
>
>
> David Fitzjarrell
Or even a link, soft or hard?
--
S. Anthony Sequeira
++
The difference between waltzes and disco is mostly one of volume.
-- T. K.
++
z1hou1
in more ways than one and definitely in ways suggested by ddf, Tony
Sequeira and David Fitzjarrell, I was actually curious why sqlldr had
this difference in behavior for accessing a file without a "." and/or
an extension between Unix and Windows. And I was particularly
intrigued why sqlldr could not recognize such a file, while the Unix
ls command recognized the same file without an extension or the
period.
.
Whatever I am doing is part of something large and runs under a
framework that invokes tools with parameters, in this case it is
sqlldr, a control file and a data file. The sqlldr not being able to
handle a file without a period or an extension came as a bit of a
shock. Having said that, I was actually appalled to see a formal file
part of a daily process given to the downstream system without an
extension.
.
I simply told the upstream people to give the downstream system the
same file with an extension and keep the solution simple and pre-
processing down to a minimum. If that is refused, yes, I will go with
a small amount of pre-processing and move on.
.
It is apparent that sqlldr on Unix/Solaris cannot recognize a filename
without an extension. I was well aware of the .dat assumption. But the
windows implementation threw me off - where it recognizes a file
without any extension or the period as long as we said
data=<filename>. (period in the end).
.
Once again, thank you all.
z1hou1
Vladimir M. Zakharychev
Windows != Unix. Different file systems, different defaults, different
assumptions, substantially different code base. If you are really
concerned with Unix sqlldr not recognizing files without an extension,
I'd suggest you file a bug on this. For me it appears illogical that
Unix sqlldr does not even attempt to open the file exactly as its name
is specified before default extension is tried in conjunction. But
maybe that's just me and you...
Regards,
Vladimir M. Zakharychev
N-Networks, makers of Dynamic PSP(tm)
http://www.dynamicpsp.com
Eric
> Thank you all for your suggestions. While I could resolve this issue
> in more ways than one and definitely in ways suggested by ddf, Tony
> Sequeira and David Fitzjarrell, I was actually curious why sqlldr had
> this difference in behavior for accessing a file without a "." and/or
> an extension between Unix and Windows. And I was particularly
> intrigued why sqlldr could not recognize such a file, while the Unix
> ls command recognized the same file without an extension or the
> period.
Because in Unix, there is no such thing as a file extension, a file just
has a name, which may contain a period if you like, and the name is all
that ls cares about. Some Unix programs (originally just the build chain)
found extensions to be useful (make was designed around using them)
but they are not necessary even in many of the cases where they are
always used.
Oracle was designed to be portable to anything that had a decent C
compiler, by having an operating system dependent layer (all the names
beginning with osd or osn that you see in error trace files). Mostly
the layer is pretty good, but sometimes it has to stretch a bit (or
even a lot), and I'm sure there are some odd edge cases that most
people never see.
> .
> Whatever I am doing is part of something large and runs under a
> framework that invokes tools with parameters, in this case it is
> sqlldr, a control file and a data file. The sqlldr not being able to
> handle a file without a period or an extension came as a bit of a
> shock. Having said that, I was actually appalled to see a formal file
> part of a daily process given to the downstream system without an
> extension.
> .
> I simply told the upstream people to give the downstream system the
> same file with an extension and keep the solution simple and pre-
> processing down to a minimum. If that is refused, yes, I will go with
> a small amount of pre-processing and move on.
> .
> It is apparent that sqlldr on Unix/Solaris cannot recognize a filename
> without an extension. I was well aware of the .dat assumption. But the
> windows implementation threw me off - where it recognizes a file
> without any extension or the period as long as we said
> data=<filename>. (period in the end).
I think the normal behaviour is that if you provide an extension, it
should be used, if you don't, the relevant default is used. I don't know
what actually happens with just the dot, but I would not be surprised at
different behaviour for different OSs. It should be the same code for
all the "traditional" utilities (sqlldr, sqlplus, exp, imp, rpt ...).
Eric