Strange behavior with IMPORT
Brian K. White
brian at aljex.com
Mon Aug 19 11:34:29 PDT 2013
On 8/18/2013 4:17 PM, Boaz Bezborodko wrote:
> I am trying to import a file and it's giving me weird results. I import
> using the following command:
>
> IMPORT ASCII ord=(File_Location{"INBOUND\ "{ae) R=\r F=, O=" C="
>
> The file I am getting is a little strange in that it has CR at the end
> of each line except the last. What is happening is that when Filepro
> reads the last line then 'ord' is populated with data, but 'not ord'
> shows as true.
>
> If I check for 'not ord' to break out of the import loop then the last
> file is not processed. If I let it go through then Filepro keeps
> reading the last line over and over with each loop.
>
> I can save the data from the last line and check against that to break
> out, but is this a bug?
You can test for not ord and something else like ord(@rn) to tell if you
are really on a non-empty, *new*, record before proceeding to ignore the
not-ord.
That way should handle the current files and still work fine when files
come in with a normal trailing linefeed some day.
then: rn = "0"
then: import ord = ...
if: not ord and ord(@rn) eq rn
then: goto fini
then: rn = ord(@rn)
I don't really know that @rn will behave the way this expects. It might
increase every time even though the file position is not really
increasing any more. You might be able to check something else that you
think you can depend on in the data itself that is guraranteed to change
with every record. Only you know what that might be. Really only the
people sending know.
Myself I would do this:
In @once, use file i/o commands to read the last byte of the file, and
if it is not already a LF, then append a LF. All in @once so it
automatically only happens once without having to check for it every
record, and it all happens before the first record is even looked at.
No pre-processing outside of filepro needed, everything stays self
contained and self documented right in the table, and you won't end up
creating blank records if these start coming in with normal trailing
line-endings some day.
@once
' get file name from cmdline
then: fn(128,*,g) = File_Location{"INBOUND\ "{ae
' open the file in both read and write mode, binary mode
then: h = open(fn,"rw")
' seek to one byte before end of file
then: x = seek(h,"1","2")
' read one byte
then: x = read(h,d,"1")
' if it is a CR, then skip the rest
if: asc(d) eq "13"
then: goto endini
' write a CR
x = write(h,chr("13"),"1")
endini:
then: close(h)
then: end ' end of @once
In the interests of keeping the example simple, I'm not checking errors
here. Those x variables you could check each time, they tell you if the
open failed, how many bytes were actually read in the read, if the write
failed, etc.
Since we are getting the file name into fn in @once, you should change
the import line and any other references to the file name to use fn.
import ascii ord = fn ...
This is all based on you're statement that the line-endings are really
just CR and not LF or CRLF. If that's not really the case, well, garbage
in -> garbage out.
--
bkw
More information about the Filepro-list
mailing list