This function makes it possible to extract the data in one or more tables in an X3 folder, by creating files containing the table description and the stored data, in a sub-directory of the folder (SVG by default). It is a physical extraction (comparable to a certain extent to an Oracle export, except that the file has a format that is not linked to a database and can be used for transfers between databases). For each XXX table of the database, four to six files are created:

  • a XXX.dat file, which contains the data in the form of a file constructed of fixed length records.
  • a XXX.srf file, which contains the description of the file structure (ASCII format).
  • a XXX.fde file, which contains the description of the file structure (in a compiled format directly usable by the Adonix engine: This file also exists in the FIL directory of the folder).
  • a XXX.seq file, which contains the next sequence number associated with the table. This information is important insofar as each table is associated with a sequence number that makes it possible to create unique numbers (this corresponds to the Adonix function uniqid([abv]), where abv is the table abbreviation).
  • a XXX.blb file, which contains the data linked to the image files (BLOBS) and text files (CLOBS) stored in the table if it has any.
  • a XXX.cfg file, which contains the table configuration information in the database. This file is optional, its presence dependent in particular on the extraction options selected. To have more information on the configuration file structure, it is advisable to consult the corresponding technical annex.

Legal notice

This type of function is a development function whose use is probibitted in a standard use framework.

Any legal consequences arising from the use of development tools on databases containing data which it is prohibitted by law to modify will be under the full responsibility of the customer. For further information, refer to the corresponding annex.

Screen management

Entry screen

When entering the function, an entry screen is displayed used to define the data to extract and the setups applied to this extraction.

The act of validating starts the function. A log file is created and viewed in order to know the result (and any possible errors in the extraction).

Block number 1

Folder (field DOSSIER)

Define the folder code, as it is defined in the folders table, in which the work will be carried out.
Historized (field HISTO)

If the folder where the tables are extracted possesses an archive folder, there is the choice to extract into the archive table (by checking the box) or in the table in the live folder (not checked).
Tables to export (field FICHIER)

Defines the name of the table to be extracted or a template characterising the name of the tables to be extracted.

If for example, all the tables present in the SVG directory are to be extracted, all that is necessary is to enter * in this field.
Backup volume (field STOVOL)

Block number 2

Copy configuration files (field CFG)

When this box is checked, the file with the extension cfg present in the directory FIL is copied into the extraction directory. This file contains the configuration directives such as the size of the extents. Its structure is described in an annex.
Real size in srf (field SIZ)

When this box is ticked, the file with the extension srf, which contains the sizing elements for the table, is created taking into account the current size of the table, and not the size planned for the table (as it is defined by the variables and sizing formulas in the folder management).

Other conditions

Technical limits

This function is linked to the adonix engine and not to the standard databases. As a consequence, it should not be used as a habitual backup procedure, since it does not have the guarantees of security or performance. A backup with the standard database tools is strongly recommended before every use of this type of function.

Amongst the limitations of this type of function, it should be noted that, if it is launched for several database tables, it can lead to a database image that is not globally coherent if updates take place during the export (unlike the standard tools associated with the databases). If the function is to be used to extract a coherent image, it is necessary to ensure that nobody else is connected to the folder during the extraction.

Practical cases:

If an extract is required to give a temporary backup in order to be able to identically reintegrate it in case of problem (for example, after an attempt at maintenance that has gone wrong before which a precautionary backup has been carried out), it is imperative to tick the box Configuration file copy, and un-tick the box Actual size in the srf. It is the value that is proposed by default in this instance.

If on the other hand an extract of all the data in a database is required in order to make it possible to reload it in another environment, for example for analysis requirements, it is necessary to un-tick the box Configuration file copy to avoid impossible constraints during the reintegration. It could be interesting at this moment to tick the box Actual size in the srf. This has as a consequence the creation of a file with the extension srf sized to the actual size of the folder. It is in this way possible to reload the tables in a folder minimising the physical space necessary in the database. This option is strongly recommended if the extraction is to serve for reloading the folder for analysis requirements or simply for the recovery of a development folder.

Batch task

This function can be run in batch mode. The standard task DOSSVG is provided for that purpose.

Error messages

In addition to the generic error messages, the following messages can appear during the entry :

XXX folder
Error when accessing table AUTILIS
Non-existent file

This error message leans that the selected folder was not created or does not exist anymore (in any case, the user table could not be found in this folder).

Other error messages

At the time of the extraction, a log file is created. Errors may occur during the operation: they appear in the form of an error line (in red) in the log file, followed by additional information.

Tables used

SEEREFERTTO Refer to documentation Implementation