1

The question may looks duplicate. But i am not getting the answer which i am looking.

The problem is, in unix, one of the 4GL binary is fetching data from the table using cursor and writing the data in .txt file. The table contains around 50 Million records. The binary took lot of time and not completing. the .txt file is also 0 byte.

I want to know the possibilities why the records are not written in the .txt file.

Note: There is enough disk space available. Also, for 30 Million records, i can get the data in the .txt file as i expected.

SuRa
  • 503
  • 2
  • 12
  • 24
  • Limit is not of .txt file (it's just a file like any other) but in programs will read/write (they may buffer each line then 32 bit limit may be reached even on 64 bit machines, it depends on character counter size and memory) it and file system (that may limit file size). – Adriano Repetti Nov 04 '13 at 13:14

2 Answers2

3

The information you provide is insufficient to tell for sure why the file is not written.

In UNIX, a text file is just like any another file - a collection of bytes. No specific limit (or structure) is enforced on "row size" or "row count," although obviously, some programs might have certain limits on maximum supported line sizes and such (depending on their implementation).

When a program starts writing data to a file (i.e. once the internal buffer is flushed for the first time) the file will no longer be zero size, so clearly your binqary is doing something else all that time (unless it wipes out the file as part of the cleanup).

Try running your executable via strace to see the file I/O activity - that would give some clues as to what is going on.

Alexander L. Belikoff
  • 5,698
  • 1
  • 25
  • 31
1

Try closing the writer if you are using one to write to the file. It achieves the dual purpose of closing the resource along with flushing the remaining contents of the buffer.

CPU calculated output needs to be flushed if you are using any mechanism of buffered writer. I have encountered such situations a few times and in almost all cases, the issue was that of flushing the output.

In java specifically, usually the best practice of writing data involves buffers. So when the buffer limit is reached, it gets written to the file but doesn't get written to the file when the end of buffer has not been reached yet. This happens when program closes without flushing the buffered writer.

So, in your case, if the processing time that it takes is reasonable and still the output is not on the file, it may mean that the output has been calculated and put on the RAM but could not be written to the file (which represents the disk) due to the output not being flushed.

You can also consider the answers to this question.

Sahin Sarkar
  • 21
  • 4