Since SAPscript does not create backup copies of texts, the old version of the text can no longer be reconstructed. The function module SAVE_TEXT is called implicitly within the function modules EDIT_TEXT and EDIT_TEXT_INLINE.
To avoid too many accesses to the text database (performance) or to synchronize the modification time of the texts with those of the application object, you can deactivate automatic storage for these function modules (parameter SAVE).
However, you must then call the function module SAVE_TEXT explicitly at the appropriate time. This is usually the time when the other application data is stored as well. This procedure ensures that the system executes all changes to an application object simultaneously.
STORE TEXTS IN UPDATE TASK If the value in the storage mode of a text is set to 'update task', this text is automatically stored. You need no extra function modules for this storage mode. The application program always calls the same SAPscript function modules, independent of the storage mode. When using storage mode 'V', at the end of the dialog transaction the application program must call a SAPscript function module that prepares the update of the texts processed so far.
Texts maintained with SAPscript consist of a text header and a table containing the text lines. The system keeps these two components in the work areas defined in the application program. The application program must provide these work areas for each text.
This means, if two text modules are edited at the same time, two structures must exist to contain the text headers and two tables for the text lines. This is necessary, if several texts are displayed and changed on the same screen. If the texts appear one after the other on different screens, you can reuse the same work areas, provided the old text has been stored.
For direct storage, this is no problem, since the changes immediately go to the text file and the system can read the text from there, if the user may need it again during the transaction. When using the update task, you are not allowed to write the text to the text file, because all database changes are executed only after the user triggered the function 'Update' in the application transaction. For this reason, changes to the text modules are stored intermediately in an administration table controlled by SAPscript: the text memory.
If the user wants to edit a changed text again during the transaction, SAPscript fetches the current version of the text from the text memory. The text memory stores the database function to be executed (insert, update or delete) as well as the text header and text lines of the corresponding texts.
At the end of the transaction, the application program must use the function module COMMIT_TEXT to tell the word processing program to pass the texts stored in the text memory to the update task. After this, the text memory is empty again, unless specified otherwise. After all data of the application program are passed to the update task, a COMMIT WORK must occur to update the texts. The function module COMMIT_TEXT itself does not execute a COMMIT WORK.
You must not change the storage mode set in table TTXOB without adapting the application programs, since, depending on this setting, the programs may have to call the function module COMMIT_TEXT and a COMMIT WORK. RENAME TEXTS The name of a text usually corresponds to the key of the application object.
However, in some transactions, this key is determined only at the moment the user executes the function 'Update'. Since texts are edited before this moment, they must have temporary names in this case. These names are then replaced by the finally valid text names shortly before calling COMMIT_TEXT.
To do this, use the function module RENAME_TEXT, which replaces temporary names with the correct text names. You must call this function module before calling COMMIT_TEXT. Otherwise, the texts are stored under the temporary names.
You can rename texts in the text memory only. TEXT MEMORY Within one transaction, the text memory contains all texts with storage mode 'V' that have been processed during this transaction using SAPscript function modules that change the text database.
Structure of the text memory Naming conventions for the text memory Text memory and CALL mode Keep texts in the text memory Change the storage mode dynamically STRUCTURE OF THE TEXT MEMORY The text memory consists of an administration table for all texts processed during the transaction. This table specifies for each text which function to execute with it.
Depending on this function, other information may be included for that particular text in the text memory. NAMING CONVENTIONS FOR THE TEXT MEMORY SAPscript stores its data in the ABAP/4 memory using different IDs. All IDs for SAPscript entries start with the character string 'SAPLSTXD'. If you work with the ABAP/4 memory within your application program, you are not allowed to use IDs that start with this character string.
TEXT MEMORY AND CALL MODE The text memory is part of the ABAP/4 memory. This means that the system keeps its contents whenever the application program calls a transaction (CALL TRANSACTION, SUBMIT AND RETURN or CALL DIALOG). Apart from transactions, this applies for reports or dialog modules as well.
All programs in this CALL hierarchy called by the application program use the same text memory and thus have access to the same texts. If one of these called programs executes a COMMIT_TEXT, the system transfers all texts to the update task, even those texts that do not belong to that particular program. In such a case, you can use the parameters OBJECT, NAME, ID, and LANGUAGE to specify exactly the texts you want to transfer. You can also use generic names.
All other texts, which do not match the selection criteria, remain unchanged in the text memory. If they are changed, you must use other COMMIT_TEXT calls to pass them to the update task. KEEP TEXTS IN THE TEXT MEMORY As described above, the text memory is empty after the final call of the function module COMMIT_TEXT.
For a new read access, the system uses the text file. If the update task is slow, the system may read the old text contents. However, some applications must continue processing texts with the same transaction after a COMMIT_TEXT, for example, to print a document. In this case, you can use the parameter KEEP of the function module COMMIT_TEXT to keep the texts in the text memory. The system flags them to indicate that they have been sent to the update task.
If you call COMMIT_TEXT again, the flagged texts are not passed to the update task, unless they have been changed again in the meantime. CHANGE THE STORAGE MODE DYNAMICALLY In certain cases, it makes no sense to change a text module using the update task (for example, background programs).
In these situations, the system must handle text with storage mode 'V' just like texts with direct storage to the database. The corresponding function modules offer the parameter SAVEMODE_DIRECT, which ensures that a text is stored immediately when calling, for example, SAVE_TEXT. However, you can also use this parameter with COMMIT_TEXT.
In this case, all texts are stored in the text memory first and written to the database together at the same time, that is, at the call of COMMT_TEXT. For these texts, you need no COMMIT WORK. WORKAREAS FOR TEXTS According to the structure of a text (text header and text lines table), programs that use the SAPscript programming interface must create the appropriate work areas to store these components of a text. The text header includes all administrative information on a text module.
To avoid too many accesses to the text database (performance) or to synchronize the modification time of the texts with those of the application object, you can deactivate automatic storage for these function modules (parameter SAVE).
However, you must then call the function module SAVE_TEXT explicitly at the appropriate time. This is usually the time when the other application data is stored as well. This procedure ensures that the system executes all changes to an application object simultaneously.
STORE TEXTS IN UPDATE TASK If the value in the storage mode of a text is set to 'update task', this text is automatically stored. You need no extra function modules for this storage mode. The application program always calls the same SAPscript function modules, independent of the storage mode. When using storage mode 'V', at the end of the dialog transaction the application program must call a SAPscript function module that prepares the update of the texts processed so far.
Texts maintained with SAPscript consist of a text header and a table containing the text lines. The system keeps these two components in the work areas defined in the application program. The application program must provide these work areas for each text.
This means, if two text modules are edited at the same time, two structures must exist to contain the text headers and two tables for the text lines. This is necessary, if several texts are displayed and changed on the same screen. If the texts appear one after the other on different screens, you can reuse the same work areas, provided the old text has been stored.
For direct storage, this is no problem, since the changes immediately go to the text file and the system can read the text from there, if the user may need it again during the transaction. When using the update task, you are not allowed to write the text to the text file, because all database changes are executed only after the user triggered the function 'Update' in the application transaction. For this reason, changes to the text modules are stored intermediately in an administration table controlled by SAPscript: the text memory.
If the user wants to edit a changed text again during the transaction, SAPscript fetches the current version of the text from the text memory. The text memory stores the database function to be executed (insert, update or delete) as well as the text header and text lines of the corresponding texts.
At the end of the transaction, the application program must use the function module COMMIT_TEXT to tell the word processing program to pass the texts stored in the text memory to the update task. After this, the text memory is empty again, unless specified otherwise. After all data of the application program are passed to the update task, a COMMIT WORK must occur to update the texts. The function module COMMIT_TEXT itself does not execute a COMMIT WORK.
You must not change the storage mode set in table TTXOB without adapting the application programs, since, depending on this setting, the programs may have to call the function module COMMIT_TEXT and a COMMIT WORK. RENAME TEXTS The name of a text usually corresponds to the key of the application object.
However, in some transactions, this key is determined only at the moment the user executes the function 'Update'. Since texts are edited before this moment, they must have temporary names in this case. These names are then replaced by the finally valid text names shortly before calling COMMIT_TEXT.
To do this, use the function module RENAME_TEXT, which replaces temporary names with the correct text names. You must call this function module before calling COMMIT_TEXT. Otherwise, the texts are stored under the temporary names.
You can rename texts in the text memory only. TEXT MEMORY Within one transaction, the text memory contains all texts with storage mode 'V' that have been processed during this transaction using SAPscript function modules that change the text database.
Structure of the text memory Naming conventions for the text memory Text memory and CALL mode Keep texts in the text memory Change the storage mode dynamically STRUCTURE OF THE TEXT MEMORY The text memory consists of an administration table for all texts processed during the transaction. This table specifies for each text which function to execute with it.
Depending on this function, other information may be included for that particular text in the text memory. NAMING CONVENTIONS FOR THE TEXT MEMORY SAPscript stores its data in the ABAP/4 memory using different IDs. All IDs for SAPscript entries start with the character string 'SAPLSTXD'. If you work with the ABAP/4 memory within your application program, you are not allowed to use IDs that start with this character string.
TEXT MEMORY AND CALL MODE The text memory is part of the ABAP/4 memory. This means that the system keeps its contents whenever the application program calls a transaction (CALL TRANSACTION, SUBMIT AND RETURN or CALL DIALOG). Apart from transactions, this applies for reports or dialog modules as well.
All programs in this CALL hierarchy called by the application program use the same text memory and thus have access to the same texts. If one of these called programs executes a COMMIT_TEXT, the system transfers all texts to the update task, even those texts that do not belong to that particular program. In such a case, you can use the parameters OBJECT, NAME, ID, and LANGUAGE to specify exactly the texts you want to transfer. You can also use generic names.
All other texts, which do not match the selection criteria, remain unchanged in the text memory. If they are changed, you must use other COMMIT_TEXT calls to pass them to the update task. KEEP TEXTS IN THE TEXT MEMORY As described above, the text memory is empty after the final call of the function module COMMIT_TEXT.
For a new read access, the system uses the text file. If the update task is slow, the system may read the old text contents. However, some applications must continue processing texts with the same transaction after a COMMIT_TEXT, for example, to print a document. In this case, you can use the parameter KEEP of the function module COMMIT_TEXT to keep the texts in the text memory. The system flags them to indicate that they have been sent to the update task.
If you call COMMIT_TEXT again, the flagged texts are not passed to the update task, unless they have been changed again in the meantime. CHANGE THE STORAGE MODE DYNAMICALLY In certain cases, it makes no sense to change a text module using the update task (for example, background programs).
In these situations, the system must handle text with storage mode 'V' just like texts with direct storage to the database. The corresponding function modules offer the parameter SAVEMODE_DIRECT, which ensures that a text is stored immediately when calling, for example, SAVE_TEXT. However, you can also use this parameter with COMMIT_TEXT.
In this case, all texts are stored in the text memory first and written to the database together at the same time, that is, at the call of COMMT_TEXT. For these texts, you need no COMMIT WORK. WORKAREAS FOR TEXTS According to the structure of a text (text header and text lines table), programs that use the SAPscript programming interface must create the appropriate work areas to store these components of a text. The text header includes all administrative information on a text module.
RELATED POSTS
No comments :
Post a Comment