Understand the purpose of storing data in a file

Programming – Understanding the Purpose of Storing Data in a File

1. Why Store Data in a File? (Syllabus wording)

The Cambridge IGCSE 0478 syllabus states that file storage is used “to preserve information beyond the life of a single program execution”. The four purposes required for the exam are:

• Persistence – data remains after the program stops.
• Sharing – the same file can be accessed by different programs or users.
• Backup – a copy can be restored if the system fails.
• Large data sets – files can hold more information than the RAM available during one run.

2. When to Use Files (exam‑style situations)

1. Data must be retained for future sessions – e.g. student records saved for the next school year.
2. Data needs to be exchanged between programmes – e.g. a quiz programme exports scores as a .csv file that a spreadsheet can import.
3. The volume of data exceeds available RAM – e.g. a library catalogue containing thousands of books.
4. An audit trail is required – e.g. a banking application writes a log file of every transaction.

3. Types of Files Covered by the Exam

• Text files – store human‑readable characters. The exam only expects knowledge of text files. Typical extensions in pseudocode are .txt and .csv.
• Binary files – store data in a program‑specific format (e.g. images). Binary handling is **not** examined in IGCSE; it is mentioned here only for completeness.

4. Advantages & Disadvantages of File Storage

5. File Modes (what the programme can do)

• READ – open an existing file for reading only.
• WRITE – create a new file (or overwrite an existing one) for writing.
• APPEND – open an existing file and add data to the end without deleting existing content.

Exam questions often ask you to choose the correct mode, e.g. “append the new score to scores.txt”.

6. Typical File Operations (including error checking)

1. OPEN the file in the required mode and verify that the operation succeeded.
2. READ or WRITE the required data, checking for errors after each operation.
3. CLOSE the file to ensure data is saved and resources are released.

In pseudocode you normally test the result of OPEN FILE. If it fails, display an error message and stop the programme.

7. Reading & Writing: Single Item vs. Whole Line

• READ item – reads a single data item (e.g. a number or a word) separated by a space or comma.
• READ LINE – reads an entire line of text, preserving commas, spaces, etc.
• WRITE item – writes a single item (no line break unless you add one).
• WRITE LINE – writes a complete line and automatically moves to the next line.

8. End‑of‑File (EOF) Handling

When reading a file you must stop when the end of the file is reached. The usual exam pattern is:

OPEN FILE "scores.txt" FOR READ
IF NOT FILE OPENED THEN
    DISPLAY "File not found"
    STOP
END IF

WHILE NOT EOF
    READ LINE line
    DISPLAY line
END WHILE

CLOSE FILE

The condition WHILE NOT EOF guarantees that the loop terminates exactly at the end of the file.

9. Example: Storing Student Scores (exam‑style pseudocode)

OPEN FILE "scores.txt" FOR WRITE
IF NOT FILE OPENED THEN
    DISPLAY "Unable to create scores.txt"
    STOP
END IF

WRITE LINE "Alice,85"
WRITE LINE "Bob,92"
WRITE LINE "Charlie,78"

CLOSE FILE

10. Example: Adding a New Score (APPEND mode)

OPEN FILE "scores.txt" FOR APPEND
IF NOT FILE OPENED THEN
    DISPLAY "Unable to open scores.txt for appending"
    STOP
END IF

WRITE LINE "Diana,88"

CLOSE FILE

11. File Location (paths)

• Relative path – e.g. "data/scores.txt" (relative to the programme’s folder).
• Absolute path – e.g. "C:\Users\Student\Documents\scores.txt" (full location on the computer).
• For IGCSE exams you will normally use a simple filename (relative path) unless the question explicitly mentions a folder.

12. Basic Security Considerations

• Set appropriate file permissions so only authorised users can read or modify the file.
• If the data is sensitive, you may mention a simple technique such as “basic encryption” (e.g., shifting characters), but the exam only requires awareness that protection is needed.

13. Summary Checklist (ordered to match AO weighting)

1. Identify whether the problem requires persistence (AO1).
2. Choose the correct file type – for the exam this will be a text file with an appropriate extension (AO2).
3. Write the correct OPEN … FOR …, READ/WRITE/WRITE LINE, and CLOSE statements using the prescribed pseudocode style (AO2).
4. Include error checking after opening the file and after each read/write operation (AO3).
5. Consider file mode (READ, WRITE, APPEND), file location (relative/absolute) and basic security where relevant.