Text
The ADONIX X3 140 version can be used to store long texts in the database. But the upgrade process from v130 to v140 does not manage this coding transfer, which can take a long time and may require a preliminary sizing study of the tables dedicated to storing of the Clobs. It is therefore this function which is used in the later coding transfer of long texts associated with the data management (orders, invoices, customers, etc.) in the database.
It should be noted that a dedicated processing for the recovery of generic data linked to the supervisor (attachments, comments, etc.) also exists.
Screen management
The function makes use of a single window in which the elements to be transferred in the database are defined.
Entry screen
The name of the folder to be processed is located in the header, as well as a Detailed log file flag whose activation triggers the creation of a line per document processed in the log file (otherwise, only the problems are signaled).
After this, there is a grid in which all the tables that can be processed are listed. This grid displays the following columns:
The code and the name of the table are listed first.
Then the code and the name of the first text field in this table. The recovery option can be specified (Plain text or Rich text). Plain texts can be manipulated like character strings while rich texts can only be manipulated as a whole. They do however benefit from the possibility to define character fonts and associated styles.
if applicable, the code and the name of a second text field to recover (there are never more than two). Here again the recovery option can be specified.
In addition, it is possible to delete lines in the grid, if the recovery is wanted on certain tables only
Finally, when the entry is complete and the screen validated, the launch of the processing triggers the integration of the texts chosen in the database. Note that, unlike attachments, these texts can be accessed in the software only after they are integrated in the database. It is therefore pointless to not carry out the integration of the totality of the texts, except maybe for operational reasons, when it is preferable to spread the integration of the texts of certain large tables in time.
In version 130, two files (one in the rtf extension and one in txt) were created in a dedicated directory. Thus, the integration algorithm reads the rtf or txt file in priority according to the option chosen. If it does not find the file of the correct type, by default it will use the file of the other type instead.
Block number 1
| Folder (field DOSSIER) |
Block number 2
| Detailed log file (field TRACE) |
| Table (field TABLE) |
| field TABLIB |
| Field (field ZONE1) |
| field ZONELIB1 |
| Option (field OPT1) |
| Field (field ZONE2) |
| field ZONELIB2 |
| Option (field OPT2) |
Refer to documentation