Skip to content

ABAP Keyword Documentation →  ABAP - Reference →  Processing External Data →  ABAP File Interface 

File Interface in Unicode Systems

Since the content of files often reflects the structure of data in the working memory, the file interface in a Unicode system must be able to cope with the following demands:

  • It must be possible to exchange data between Unicode and non-Unicode systems.
  • It must be possible to exchange data between different Unicode systems.
  • It must be possible to exchange data between different non-Unicode systems that use different code pages.

For this reason, in Unicode programs, the code page used to encode character-like data must always be defined. This is the data written to or read from text files. A Unicode program must also be executable in both Unicode and non-Unicode systems. This why the following syntax rules apply in Unicode programs, which are less error-prone than the rules in the obsolete non-Unicode programs:

  • A file must be opened explicitly before every read or write operation. Furthermore, a file that is already open cannot be opened again. In non-Unicode programs, the first time a file is accessed, it is opened implicitly using the standard settings. The statement for opening a file can be applied to an open file in non-Unicode-programs, although a file can only be opened once within a program.
  • The access method and data storage type must be specified explicitly when a file is opened. In non-Unicode programs, if nothing is entered, a file is opened with implicit standard settings.
  • If a file is opened for reading, the content can only be read. In non-Unicode programs, it is also possible to gain write access to these files.
  • If a file is opened as a text file, only the content of character-like data objects can be read or written. In non-Unicode programs, byte-like and numeric data objects are also allowed.

Other versions: 7.31 | 7.40 | 7.54


Note

Normally explicit programming is required, where all important parameters must be entered, rather than programming with default settings, over which the developer has no influence. Furthermore, error-prone mixed forms of byte-like, character-like, and numeric data are not allowed.