sqlldr not recognizing a file without an extension on Solaris
in [Oracle]
|
From: John Hurley on 19 Feb 2010 08:33 On Feb 18, 11:38 pm, z1hou1 <z1h...(a)gmail.com> wrote: snip > Versions of db and o/s > 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 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 ...
From: ddf on 19 Feb 2010 09:02 On Feb 18, 11:38 pm, z1hou1 <z1h...(a)gmail.com> wrote: > Versions of db and o/s > 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 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
From: Tony Sequeira on 19 Feb 2010 09:10 ddf wrote: [...] > > 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. ++
From: z1hou1 on 19 Feb 2010 12:11 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
From: Vladimir M. Zakharychev on 19 Feb 2010 14:10
On Feb 19, 8:11 pm, z1hou1 <z1h...(a)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 |