I have a process that generates a .txt file (fixed length) from an Oracle concurrent process. Originally, this was just picked up from a Linux directory and ftp'd to Windows directory. To automate the process, a mount point was established on the Windows server. The problem we are now seeing is that a control character (end of file) is seen at the end of each row. Can we do something in the program to control this? The problem is that the 3rd party software reading the file reads one row and then stops due to the control character.
-
-
How do you know it's printing a end of file character at the end of each row? Could it be that linux uses 1 character for a new line and windows uses 2 characters? And therefore the program never moves to the next row because it never finds those characters? -
When we examine the file that was generated thru the mount point, you can see small box at end of row of information, immediately prior to next row of info. When 3rd party reporting tool brings this file in, it reads the first row and then sees end of file. I can only see this character in Windows XP, though. I am not sure how to see the details behind this small box so I can't answer your question if there is 1 character or 2 that make up the smal box.Comment
-
Exactly. It's unlikely it's a end of file character. A box merely means that it is an unprintable character. Use a hex editor to see what character it actually is. I am willing to bet it is a line feed character.
Linux uses only a line feed to represent a new line while windows uses a carriage return (CR) and line feed (LF). If your program is expecting to see both characters but your file only contains one of them, the program will error out. It's not because of an end of file character.
The solution is simple, whatever you're using to output the file, see if there's a setting to use a CRLF as the record delimiter. If not, as part of your automation, replace all LF with CRLF before running your other program.Comment
Comment