Re: sqlldr not recognizing a file without an extension on Solaris
From: Vladimir M. Zakharychev <vladimir.zakharychev_at_gmail.com>
Date: Fri, 19 Feb 2010 11:10:33 -0800 (PST)
Message-ID: <9f41e5fb-2a41-4c2e-b3c0-4998f6f1917a_at_a18g2000yqc.googlegroups.com>
On Feb 19, 8:11 pm, z1hou1 <z1h..._at_gmail.com> wrote:
> 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.
> .
> 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
Date: Fri, 19 Feb 2010 11:10:33 -0800 (PST)
Message-ID: <9f41e5fb-2a41-4c2e-b3c0-4998f6f1917a_at_a18g2000yqc.googlegroups.com>
On Feb 19, 8:11 pm, z1hou1 <z1h..._at_gmail.com> wrote:
> 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.
> .
> 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
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
Received on Fri Feb 19 2010 - 13:10:33 CST