The statements
of the ABAP file interface enable files to be processed on computers on the
application server using ABAP statements. For files on the
presentation server, function modules or global classes are available.
In all statements of the file interface, files are addressed directly using the name under which they are known on the current platform. A file therefore cannot be opened more than once within a program. The name of a file is normally composed of a file path and the name of the file. The notation used depends on the operating system of the application server. If a file name is specified without a file path, the directory stored in the profile parameter DIR_HOME is used automatically.
If writing cross-platform programs, SAP recommends that you use the transaction FILE to create logical file names and logical paths, which can be linked to every platform using actual names. The function module FILE_GET_NAME can be used to determine a logical file name for the actual name that is valid for the current platform. This name can then be used in statements of the file interface.
In Unicode programs, file names that contain blank characters are permitted. If the specified file name in a non-Unicode program contains blank characters, it is cut off after the first blank character. In Unicode programs, the blank characters are a part of the file name.
File access authorizations can be viewed on three different levels:
From the perspective of the operating system on the application server, all file accesses are executed by the ABAP system. As a consequence, the user of the operating system on which an ABAP-based SAP system is installed must have read and write access to all directories and files that are used by the ABAP file interface. If the user does not have an appropriate authorization, the statements of the file interface cannot be executed, or only partly. If a statement cannot be executed due to a missing authorization in the operating system, the return value sy-subrc is set to a value that is not 0.
If files are accessed using the statements , OPEN DATASET, TRANSFER, and DELETE DATASET, the system automatically checks the entries in the database table SPTH. The entries in the database table SPTH control general read and write access from ABAP programs to files, and whether files should be included in a safety backup procedure.
In the database table SPTH, read and write access to generically specified files can be generally forbidden, regardless of
authorization objects. For the
remaining files (files for which read or write access is generally permitted in the database table SPTH,
authorization checks can be performed based on authorization objects. For this, authorization groups
for program-independent authorization checks can be defined in the database table SPTH. The following
table shows the columns of the database table SPTH. If the check of the database table SPTH has a negative result, this leads to an untreatable exception.
| Column | Meaning |
| PATH | Column for generic file names. The properties specified in the other columns of this line apply for all files of the application server for which the entry in this column is the most appropriate. |
| SAVEFLAG | If this column contains the value "X", the files specified in the column PATH are saved in a backup procedure. |
| FS_NOREAD | If this column contains the value "X", the files specified in the column PATH cannot be accessed from ABAP. This setting overrides the settings in the columns FS_NOWRITE and FS_BRGRU and the authorization check using the authorization object S_DATASET. |
| FS_NOWRITE | If this column contains the value "X", no write access is permitted from ABAP to the files specified in the column PATH. This setting overrides the settings in the column FS_BRGRU and the authorization check using the authorization object S_DATASET. |
| FS_BRGRU | In this column, you can define a name of your choice for an authorization group. The files of several lines can then be grouped into authorization groups. When the database table SPTH is evaluated, an authorization check for the current user is performed against the authorization object S_PATH. This authorization object contains an authorization field RS_BRGRU and an authorization field ACTVT, which are used to permit user-specific access to the files specified in PATH. If no name is specified, no authorization check against the authorization object S_PATH is performed. |
In contrast to the authorization check using the authorization object S_DATASET, the check against the authorization object S_PATH is independent of the ABAP program being used. This check is also not restricted to an individual file, instead it includes all generically specified files in the column PATH.
Before each time a file is opened or deleted using the ABAP file interface, an authorization check is carried out for the current user and the current program with the predefined authorization object S_DATASET. This authorization object has the authorization fields PROGRAM for the program name, FILENAME for the file to be opened, and ACTVT with the activities delete, read, write, read with filter, and write with filter. If the user does not have the appropriate authorization, this leads to a treatable exception (as of release 6.10). To avoid this exception, the function AUTHORITY_CHECK_DATASET can be called before the relevant ABAP statement, to check whether the authorization exists.
The database interface does not have an integrated lock mechanism to ensure that only one ABAP program accesses a file at any one time. If several programs simultaneously gain write access to a file, this will have unpredictable results.
To avoid this situation, SAP locks can be assigned, or unique file names such as GUIDs can be used.
If several application servers of an application layer access a file at the same time, conflicts may
still arise even if SAP locks are used (for example, if the operating system buffers data before it is written to a file).
As the content of files often reflects the file structure in the working memory, the file interface in a Unicode system must satisfy the following requirements:
For this reason, Unicode programs must always specify which code page is used to encode character-type data that is written to or read from text files.
Further to these conditions, it must also be possible to execute a Unicode program in both Unicode and non-Unicode systems. Some syntax rules for the file interface have therefore been changed to programming file access in Unicode programs less prone to errors than in non-Unicode programs:
Essentially, instead of implicit programming with standard settings on which the developer has no influence, explicit programming is required in which all the important parameters must be specified. Mixed format files containing a combination of byte-type, character-type, and numeric data are prone to errors and are forbidden.
SAP therefore recommends that you always follow the syntax rules for Unicode programs when using the file interface, even if you are not using a Unicode system.
As of release 6.10, files larger than 2 GB can be edited on all platforms that support this file size. Only the operating system OS/390 is still excluded from this.