Refer to the implementation documentation.This function is used to create and update a folder. A folder is a complete reference, identified by a code, in which is found all the parameters and management rules and all the data used. A folder is characterized by:
The creation of a folder is essential before starting to set up and/or enter data. This operation is relatively long. It is common practice to re-validate a folder in setup progress when the configuration is changed. However, when the folder is to be used in production, it is best to create it directly with the proper parameters. In fact, this phase will determine the correct initial sizing for the database and will avoid the later requirement to use the operation tools of the database to resize it. In addition, in the production folder, a revalidation can be a relatively long operation and requires that no one be connected to the folder being processed.
A reference folder is always the starting point for the creation of a folder. The benefit in using a reference folder is to be able to start with the basic setup. The supervisor folder, which can serve as the reference folder, and which contains all the parameters relative to the current language/country, is delivered with the software, but any other folder can act as the reference.
The creation/copy of a folder depends on the options selected for your license.
Click Create to recover by default all the set up options (modules, activity codes, languages, etc.).
You can only select the options you acquired when purchasing the software license.
The X3 record including all options cannot be copied.
Refer to the implementation documentation.
The parameters of a folder are defined in the folder table. As long as the folder has not been created (i.e. validated using the corresponding button), these parameters can be modified as required.
After creation, only some parameters remain available for modification.
In order for a modification to be taken into account, the folder must be re-validated. This operation may be rather long since it may involve a change in the structure of heavy tables and a regeneration of the software screens and windows.
However, some parameters can be modified and considered with no further folder revalidation. This is the case for the Specific folder and Test folder information. The general rule still remains that folders should be revalidated for any new parameter to be considered.
A folder is defined by an alphanumeric code of over 10 characters, to which a set of parameters defined on tabs is linked.
The following fields are present on this tab:
Folder (field DOSSIER) |
The name of the folder can take a maximum of 10 alphanumeric characters. The first letter must be alphanumeric. |
Name (field NOMDOS) |
Enter the description of the relevant record. This long description is used as a title in screens and reports. |
Use this section to define the main organizational information for folder definition.
The following fields are present on this tab:
Database type (field TYPDBA) |
Define the database used to create the folder. This database can be SQL SERVER or ORACLE. As a function of the license that is used, this choice may be possible or imposed. |
Volume (field VOLUME) |
This SAFE X3 volume number corresponds to the directory from where the physical files (not in the database) describing the folder objects are placed on the process server. The SAFE X3 volumes are defined in the "adxvolumes" file in the installation directory (contained in the ADXDIR environment variable). The default volume is A, but others can be defined on installing the software. It is possible to select the volume using the F12 key. Please refer to the technical appendix on volumes at the end of the folder management documentation. |
Containment type (field TYPCNM) |
Use file groups (field GRPFIL) |
This question is asked in the case of a SQL database server is used to define if separate files are created or not to store the indexes and the data (for the important databases this is the normal case). |
Data size (field SIZDAT) |
These values are used to size the data files and the index in the database. The size is expressed in Mega-bytes. These values are only interesting from the point of view of folder creation, and they are generally entered at the end of the definition of the folder parameters, just before the actual folder creation. In fact, to have available a correct estimate for the value, it is important to have previously sized the database tables by means of the sizing values ( Tables tab), and to have more importantly defined the table structure of the database by means of the activity codes (Options, Screens, Specifics). |
Index size (field SIZIDX) |
Format (field CODDBA) |
Defines the set of characters used to store the character fields in the database. It can take the values ASCII or UNICODE.
Internally and independently of the database format (for its temporary variables), the SAFE X3 engine uses the UTF8 format (the process sources are coded in UTF8), and the Windows client uses the UCS2 standard. |
Reference folder (field DOSREF) |
The reference folder must be an existing folder, where the data dictionary will be used during the intialization of the folder. A link is made between a folder and the reference folder. Thus, by default, if a resource (process, table, report) is not found in the current folder, it is looked for in the reference folder, by an inheritance mechanism. This value is taken by default in the copy folder, the folder from which, during the creation of the folder, it is possible to copy certain data (parameters, accounting plan...) as well as indicated in the Init tab. |
Copy folder (field DOSCOP) |
|
The copy folder, which must have been created previously, is the folder from which the data defined by the Init tab will be copied. This folder can be the reference folder, but equally another folder with an identical structure (for example, a parameterization folder in which the parameterization has been refined during the analysis phase, in which certain data can be introduced or recovered by import). It is important that the structure of the copy folder is identical (even if no control can be made, errors could be produced during the copy if this is not the case). |
Purge folder (field DOSHIS) |
This folder cannot be entered directly in the management of the folder. It is entered when an archiving folder is created after the creation of the live folder, by the corresponding function. The archiving folder is used to store the data considered as not changing, so that they can be consulted off-line. |
Start date (field STRDAT) |
This date is used to define the date of the first financial year for a newly created folder. This date is fundamental, because it cannot be changes at a later date. It corresponds to the start date of the first financial year from which the enterprise data will be managed with the software. Warning, it is advisable (for balances) to start from the previous financial year to the one that the installation will actually start with. By default, the value of two supervisor parameters STRDAT and ENDDAT, which define the possible connection period, will be defined by:
These parameters, which can be modified later, are used on the connection to the folder. It is controlled so that the entry date is contained between the dates defined by these 2 parameters. |
Folder currency (field RPTCUR) |
Makes it possible to update the parameter SYSCUR in the folder. This parameter cannot be further modified by the folder management after the generation of the folder. |
Test folder (field TSTFLG) |
The Test folder signifies that this folder is designed to receive a copy of the standard processes present in a patch, if this must be installed in the folder. If this flag is not set, the patch processes will only be integrated at the supervisor folder level. The fact of having this flag set makes it possible to carryout integration tests for patches in a folder. Once the patches in question have been fully integrated in this environment, it is advisable to "clean up" by deleting previously installed processes (if not, the next patch or version installation will not be taken into account by these processes, which risks the appearance of malfunctioning). A production folder must not have this flag set. |
Specific folder (field SPEFLG) |
This check box signifies that the specific/custom processes present in a patch will be installed in the folder even if they did not previously exist. The specific processes are identified by their name: They start either by X, Y or Z, or else by SPE, else they start with CNS and finish with SPE. If this flag is not set, only the previously existing specific/custom processes will be replaced in the folder by the new version present in the patch. |
Description (field LIBMOD) |
Active (field MODULE) |
This grid contains the modules retained for the folder to be generated. Only the functions and the tables associated with the activated modules will be usable in the folder once it has been created. It is recommended to only enter the modules that are actually useful. In effect, this makes it possible to create only the tables and objects actually used and keep to a minimum the creation time and disk space taken. It is always possible to add modules at a later date. The list of modules and any constraints are given in an appendix at the end of the documentation describing the management of the folder. |
Image size (field BLBLNG) |
This field determines the maximum size taken by default in the blob files (binary large objects) stored in the database. These fields correspond notably to the images stored in the database. This field is defined as having the power 2: 1 equivalent to 2 Kb, 2 to 4 Kb, 3 to 8 Kb and so on (the corresponding value is displayed up to 20, which corresponds to 1Gb). It should be noted that each field of the type blob can be sized differently in the database (if the database type carries an explicit length, this default length is not used). |
field BLBTXT |
Text size (field CLBLNG) |
This field determines the maximum size by default in the clob fields (character large objects) stored in the database. These fields corresponds notably to the texts stored in the database. This field is defined to the power 2: 1 equivalent to 2 Kb, 2 to 4 Kb, 3 to 8 Kb etc (the corresponding value is displayed, it can go up to 20, which corresponds to 1 Gb). It should be noted that each field of the type clob can be sized differently in the database (if the data type carries the length explicitly, this default length is not used). |
field CLBTXT |
The following fields are present on this tab:
Code (field CODACT1) |
An activity code is used to:
If the activity code is disabled:
|
Description (field LIBACT1) |
Title associated with the previous code. |
Module (field MODULE1) |
Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
Active (field FLACT1) |
If this check box is selected, the tables and screens or fields of these tables and screens related to this activity code can be accessed. If this check box is not selected, the screens and tables, or their respective fields, can no longer be accessed and are not displayed. Caution: On operation, any activity code status change requires:
|
Code (field CODACT2) |
An activity code is used to:
If the activity code is disabled:
|
Description (field LIBACT2) |
Title associated with the previous code. |
Module (field MODULE2) |
Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
Active (field FLACT2) |
If this check box is selected, the tables and screens or fields of these tables and screens related to this activity code can be accessed. If this check box is not selected, the screens and tables, or their respective fields, can no longer be accessed and are not displayed. Caution: On operation, any activity code status change requires:
|
New values |
This section displays two tables including the activity codes related to the data structure you wish to display in the screens. These codes can be set to Yes or No:
As of version 6, the multi-legislation evolution of the software lead to changing the activity codes linked to some legislation. In fact and from now, a single activity code is assigned by country to designate the legislation. This code comprised of 3 characters starts with K. To activate an activity code of this type means that the folder table structures and the corresponding parameters make it possible to manage standard-used data and processes in the relating countries. Then, the legislation used by each company must be defined using company level parameters.
The activity codes below are available:
Activity code |
Legislation concerned |
KFR |
French |
KUK |
English |
KIT |
Italian |
KPO |
Portuguese |
KSP |
Spanish |
KUs |
American |
KCh |
Chinese |
KAG |
Argentina |
KRU |
Russian |
KPL |
Polish |
KSW |
Switzerland: |
Caution, the fact that the activity code is present doe not guarantee that all the legislative constraints of the given country are dealt with. This means simply that some specific rules linked to the legislation of the country have been carried out or planned for the future and that they are controlled by said code.
Note that all the possible codes do not necessarily appear in this grid; only the active codes taking into account in the retained modules are presented.
It is important to note that when a folder is created from a reference folder other than the supervisor folder, only the activity codes that have been set to Yes in the reference folder can be set to Yes in the created folder. In this way, if another folder is created later from the folder where options are defined, it is necessary that all the required options in the final folder are present in the reference folder at creation time.
The following fields are present on this tab:
Code (field CODACT3) |
An activity code is used to:
If the activity code is disabled:
|
Description (field LIBACT3) |
Title associated with the previous code. |
Module (field MODULE3) |
Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
Screen size (field DIME3) |
Use this field to defined the number of dimensions used in the related screens and tables. A table can be limited by a maximum and minimum size. Use the following formula to define the dimension of tables: min(max(MIN,SCREEN),MAX). This field can only be accessed for activity codes of the Sizing type. |
Min extension (field DIMIN3) |
Define the minimum number of columns stored in the database (independently of the number displayed in the screen, which can be lower). This is used to avoid the standard reports making reference to columns not likely to exist according to the parameterization. |
Max extension? (field DIMAX3) |
Define the maximum possible dimension taken into account in the table structures in the database. |
New values |
Help |
In this tab, a single table appears. It contains the activity codes of two types, which are related to:
A positive value must thus be entered with respect to these activity codes.
The activity codes of the first type are only used to define a quantity of memory used for the screen, their modification involves only the revalidation of the concerned screens and windows. It is however important to note that seriously over-sizing certain values for this table will incur the need to have available increased amounts of allocated memory for each workstation. If the memory sizing is insufficient, the No more memory available error message is likely to be displayed on the screen during the use of the software, the function concerned being stopped. It should be noted that it is possible to define additional memory quotas for the given menu profiles (if certain functions that are particularly heavy memory consumers are reserved to certain users only, this can be set up in this way).
With respect to each activity code of second type, a dimension is entered to define the number of values that can be entered in the associated screens, but also the structure of the corresponding tables in the database. Modifying these values thus results upon re-validation of the folder in a structure change of the concerned tables.
A maximum value applied to the database is displayed for this activity code type. This value cannot be exceeded as this would create a table where the number of columns or the size of lines would exceed the accepted values.
In some cases, a minimum value for the database can be displayed. If the value entered is inferior to this value, it will be possible to enter less occurrences in the screens than what the database can store. If the entered value is superior, both sizing will be identical. This minimum value exists because if some fields were not in the database, there is a risk that the standard Crystal Reports might not work anymore.
The following fields are present on this tab:
Code (field DIMCOD) |
|
The sizing elements are used in the sizing formulas calculations to estimate the number of lines planned for each table and from this are used to calculate the planned size of the tables. |
Description (field ZDIMCOD) |
Module (field MODULE5) |
Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
Value (field NBR) |
This number corresponds to the value linked to the sizing element of the line. |
Help |
Is used to access the help defining the aim of the sizing variable, the values it can have and the impacted functions. |
This section is used to enter information that will be used by a sizing algorithm to calculate:
It is important to have good information for these parameters in taking into account the history desired (if by example, there is a database with 500,000 records per year and 5 years of history is desired, it is necessary to allocate 250,000 to the corresponding VOUCHER parameter). In effect, if this is not done correctly, a reorganization of the database and its parameters will be necessary at a later date to avoid fragmentation of the data and to obtain an optimal response time.
The following fields are present on this tab:
Module (field MODTR) |
Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
Y/N (field TRVAL) |
A positive response to the question leads to the validation of the transactions associated with the module. |
Languages (field LAN) |
Grid used to enter the languages that may be used in a connection to the folder. The validation of the folder causes the entry screen generation in all these languages: this operation consumes a lot of system resources. |
Translation ref. (field LANREF) |
This check box can only be checked if the following two connections are met:
It is used to specify that the current folder is the reference folder for the translation of the language in question, that is to say it is the folder that carries the most up to date translations for the language concerned. By default for the languages shipped as standard, it is of course the root directory, which is explain that the box can no longer be checked in a standard folder; but for the "non standard" languages the user is free to define a translation reference folder. A control verifies the uniqueness of the translation reference folder for a language, in order to change it, it is first necessary to un-check the folder previously set as the reference. If for a language, there is no reference folder is checked, it is selected in the following order:
|
Legislation (field LEGDOS) |
Copy options (field LIBCOP) |
Each group corresponds to a coherent group of tables in the copy folder, tables where the contents can be copied in the folder currently being parameterized during its creation. By right click on the field access is obtained to the list of tables where the contents can be copied if the response is Yes. |
Y/N (field OPTINI) |
As a function of the response, the data is copied or not from the folder copy. This copy is only carried out during the creation of the folder or in the case of the creation of the tables following the activation of a new module. |
Default language (field LANDEF) |
Makes it possible to update the parameter LANGAGE (main language) in the folder. This parameter is used to define a connection language when it is not specified for instance in the case of batch processes. |
Default country (field CRYDEF) |
Used to update the CRYDEF parameter during the creation of the folder This parameter corresponds to the country proposed by default on entry of the addresses. |
Recoding list (field CHGCOD) |
This field is used to give a screen that defines a list of recodification codes. If this screen is entered, at the end of the creation, the setups copied from the reference folder are renamed according to the renaming rules defined by the considered codes (taken in the order). This is particularly useful when, for example, the user wants to create a single-legislation folder: some setup codes, prefixed by a legislation code, are particularly heavy to use in that specific case, and the recodification can simplify the use of setups afterwards. |
Screen update (field CREMSK) |
These fields are always selected in the normal delivery environment. They are used by the editor, when developing, to revalidate a folder for testing without having to generate the code corresponding to the options presented (screens, objects, windows, inquiries). |
Windows (field CREWIN) |
Object update (field CREOBJ) |
Inquiries (field CRECNS) |
Help |
In this tab, you define the default values used upon actual folder creation and parameters affecting the way a folder is to be re-validated:
The following fields are present on this tab:
Module (field MODTR) |
Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
Y/N (field TRVAL) |
A positive response to the question leads to the validation of the transactions associated with the module. |
Languages (field LAN) |
Grid used to enter the languages that may be used in a connection to the folder. The validation of the folder causes the entry screen generation in all these languages: this operation consumes a lot of system resources. |
Translation ref. (field LANREF) |
This check box can only be checked if the following two connections are met:
It is used to specify that the current folder is the reference folder for the translation of the language in question, that is to say it is the folder that carries the most up to date translations for the language concerned. By default for the languages shipped as standard, it is of course the root directory, which is explain that the box can no longer be checked in a standard folder; but for the "non standard" languages the user is free to define a translation reference folder. A control verifies the uniqueness of the translation reference folder for a language, in order to change it, it is first necessary to un-check the folder previously set as the reference. If for a language, there is no reference folder is checked, it is selected in the following order:
|
Legislation (field LEGDOS) |
Copy options (field LIBCOP) |
Each group corresponds to a coherent group of tables in the copy folder, tables where the contents can be copied in the folder currently being parameterized during its creation. By right click on the field access is obtained to the list of tables where the contents can be copied if the response is Yes. |
Y/N (field OPTINI) |
As a function of the response, the data is copied or not from the folder copy. This copy is only carried out during the creation of the folder or in the case of the creation of the tables following the activation of a new module. |
Default language (field LANDEF) |
Makes it possible to update the parameter LANGAGE (main language) in the folder. This parameter is used to define a connection language when it is not specified for instance in the case of batch processes. |
Default country (field CRYDEF) |
Used to update the CRYDEF parameter during the creation of the folder This parameter corresponds to the country proposed by default on entry of the addresses. |
Recoding list (field CHGCOD) |
This field is used to give a screen that defines a list of recodification codes. If this screen is entered, at the end of the creation, the setups copied from the reference folder are renamed according to the renaming rules defined by the considered codes (taken in the order). This is particularly useful when, for example, the user wants to create a single-legislation folder: some setup codes, prefixed by a legislation code, are particularly heavy to use in that specific case, and the recodification can simplify the use of setups afterwards. |
Screen update (field CREMSK) |
These fields are always selected in the normal delivery environment. They are used by the editor, when developing, to revalidate a folder for testing without having to generate the code corresponding to the options presented (screens, objects, windows, inquiries). |
Windows (field CREWIN) |
Object update (field CREOBJ) |
Inquiries (field CRECNS) |
Help |
This section displays a table containing the values and characteristics associated with the activity codes starting with X, Y, or Z, which makes it possible to identify all specific/custom developments.
The following fields are present on this tab:
Code (field CODACT4) |
|
Defines the custom/specific activity codes (i.e. starting with X, Y, or Z), which can be activated in the folder. |
Description (field LIBACT4) |
|
Title associated with the previous code. |
Module (field MODULE4) |
|
Select a module for the setup. Use this field to specify if the screen has to be created in the folder database. This is the case when the module linked to the screen is active on the folder. |
Active (field FLACT4) |
If this field is set to Yes, the fields marked by the activity code in the dictionary are activated. |
Dimension (field DIME4) |
This dimension associated with a specific/custom activity code is used to size the grids and multi-occurrence fields marked by the activity code in question. |
Vertical (field COP) |
This indicator must be set to Yes in the case where:
If the indicator is set to No, the specific/customizations will not be updated when a revalidation is carried out if they exist already. This flag is used to distinguish the vertical developments that are likely to be installed in a group of folders and updated by revalidation at three levels, and the developments made in the folder at the lowest level (developments carried out by the customer for example). For more information, it is advisable to refer to the corresponding technical annex. |
This section defines the sizing elements used by the runtime of the server processes for each open session. The entered data is stored in a configuration file named APL.ini, located on the server, in the folder root directory, once it is created. These parameters have a minimum value that will be used if the set up values in this screen are not sufficient.
The following fields are present on this tab:
Engine process memory (MB) (field MEM) |
|
This parameter corresponds to the memory size used for the local data during the execution of the server process. By default, 16 Mb is proposed, this is a reasonable value even if the minimum value possible is 4 Mb. It is possible to increase it as a function of the maximum number of lines used for the large tables in memory (orders, invoices, postings). The higher the given values in the Screens tab, the greater the need to increase the necessary memory size. The system variable maxmem is used to identify the current value during a session. |
field MEM1 |
Database process memory (MB) (field MSA) |
This field is used to define the memory size allocated to the process accessing the database (it is named sadora or sadoss according to the database). The default value is set to 20Mb, which only needs changing on rare occasions. The system variable sadmem is used to identify the current value in a session in execution. |
field MSA1 |
Programs (field MPR) |
This parameter is used to define the maximum number of processes open simultaneously in a software session. The default value is 200, the minimum value being 100. A higher number will improve the performances by limiting the reloading of processes. The system variable adxmpr is used to identify the current value during a session. |
field MPR1 |
Open tables (field MTO) |
This parameter is used to define the maximum number of tables in the database simultaneously on line in a software session. The default value is 150 and it is appropriate in most cases. The system variable adxmto is used to know the current value during a session. |
field MTO1 |
Sequential files (field MSO) |
This field is used to define the maximum number of sequential files open simultaneously in a software session (by the instructions Openi, Openo, Openio). The default value is 10, the minimum value being 10. Except to very specific cases linked to these instructions, this value has no reason to be modified. The system variable adxmso is used to identify the current value during a session. |
field MSO1 |
Class memory (field MST) |
field MST1 |
Link activation |
Link test |
This section defines the folder connection characteristics, such as the information found in the connection box when logging into the folder. The information entered here is used to update a configuration file located on the server, in the root directory of the Supervisor folder, named X3APPLI.ini. This file can be remotely loaded onto the client workstations using a dedicated button from the connection settings box.
This section is also used to define the folder links to folders located on other solutions (i.e. on another server or another connection service, or both).
It has the advantage of making easier the use of connection between softwares in SAFE X3 technology when they have to share or update common data. A typical example of this kind of cooperation is when a software must update financials situated on a remote folder.
From a technical point of view, a program situated in a folder DOSSIER1 is likely to open tables from a remote folder named DOSSIER2 via a syntax of type:
File ="serveur:[email protected]"
When this happens, a process for data access is opened on the remote folder (it is called sadora or sadoss depending on the concerned database) and tries to connect to the database with a default user name (in the database context) equal to the DOSSIER1 code from the folder where the request was launched.
If it exists, it is not a problem but the access rights to the tables from folder DOSSIER2 have to be sufficient.
If no folder with name DOSSIER1 exists on the remote folder, no access will be possible, except if a directory DOSSIER1 was defined on the remote folder, containing a minimum number of strategic files used when starting this type of process (files .users, .password, APL.ini, adxora).
The adxora file stores the user code that the data access process uses to log in, and the corresponding password.
In this section, you need to enter the table of links with sufficient parameters to create the files that authorize the remote connection. This creation is not triggered when entering the line but when the link is activated (using the Actions icon).
Note that the links can be characterized by function: an Accounting link, for example, corresponds to a link through which a software can access a remote accounting. Only one characterized link of each type is available by folder, and in this case the exhaustive characteristics of the remote folder to be connected to are to be specified. These characterized links have the following advantage: they are managed by softwares which support them (an accounting operation is a software without accounting will explicitly look for an accounting link in order to know whether it should access a remote accounting).
Links of Miscellaneous type also exist: there can be several of this type for a given folder (knowing that the total number of links, all types together, is limited to 5). They are supposed to be managed in custom/specific processes. A link of this type does not identify compulsorily a specific folder: it can also correspond to a given environment. If this is the case, the connection occur with a database user code to be specified.
Upon entry of the link lines, the processing looks for the version of the SAFE X3 software installed in the target environment. It detects notably the presence of a file solution.xml, which makes it possible to deduce a certain number of values by default upon entry of a line. If no such file exists, the processing supposes that the remote folder is in version 13X.
Folder (field CDOSSIER) |
This field, display only, corresponds to the code for the folder being worked on. |
Application server (field CSERVEUR) |
Corresponds to the name or the network address of the application server, that is to say the server one which is stored the reference for the folder (notably the directories for the different folders in the solution). |
Port (field CPORT) |
Defines the TCP/IP port in which the connection server expects the connection requests from the folder. |
Access path (field CPATH) |
Display only, this field corresponds to the root directory of the folder as it is defined on the application server. It is defined as a function of the volume entered in the first tab of the folder record. When connected to the folder itself, this information can be found by entering the instruction:
|
Process server (field CSERVTRT) |
Corresponds to the name or the network address of the process proposed by default (there may be more than one and by default it can be the application server). A process server is a server on which the application code transmitted by the application server is executed. |
Publication directory (field CPUB) |
Corresponds to the applications server directory from which the XML elements defining the user interface are created. This field is not displayed, its value being defined as a function of the installation. |
Solution folder (field SOLDOS) |
Authorization granted for the current folder (field SOLAUZ) |
Link type (field LTYPLIEN) |
Defines the type of link:
|
Active link (field LLIENACT) |
Field only displayed if the link is identified as active. This field is stored in the table of folders, but an existence control on the remote directory is made on the active when the tab is displayed. |
Machine (field LMAC) |
Network path defining the remote server to be connected to. |
Service (field LSERV) |
Number of the remote server to which a connection is made. |
Directory (field LREP) |
Installation disk address for the remote solution. It is this location that the directory that is used in the remote connection will be created if a folder of the same code as the current folder does not exist. This address corresponds to a database directory (volume 0 in adxvolumes) on the application server. |
Type of OS (field LTYPOS) |
|
Defines the operating system of the server to which the link is made. |
Linked folder (field LDOSTARG) |
Define the linked folder to be connected to. This information is mandatory when the link is characterized, but not for a miscellaneous link. |
Solution (field LSOL) |
This field, only displayed, gives the name of the solution (in the SAFE X3 sense of the term), if the latter can be found in the xml configuration file (i.e. subject to a connection to an environment greater than or equal to Version 140). |
Database type (field LTYPDBA) |
Define the database type to which the user is to be connected. |
Name of the database (field LDBA) |
Corresponds to the name of the remote database. This information is recovered in the solutions.xml file if the link points to an environment for a version greater than or equal to 140. |
Data source (field LSRC) |
This field (display only) gives the name of the ODBC data source if this can be found in the configuration.xml file (i.e. if connecting to an environment where the version is greater than or equal to 140). |
DBMS user (field LUSR) |
Defines the user code (in the database sense) used for the connection. |
Password (field LPWD1) |
Defines the password (in the database sense) for the user to be used to connect to the remote database. |
System user (field LUSRJAV) |
This is the platform used by the Bridge Java to open a remote session. |
Password (field LPWDJAV) |
This is the password of the User platform used by the Bridge Java to open a remote session. |
Link activation |
Triggers an update of the link, that is the creation of the directory corresponding to the code of the folder being set up on the remote folder with the necessary configuration files. If the directory exists already and corresponds to a directory of a "true" remote folder (a check is carried out to verify if there is a sub-directory TRT), nothing is changed in order to avoid perturbations in the connections to the folder on the origin folder. But in this case there is nothing to do since the connection is achieved remotely (with the privileges of the user BDD corresponding to the folder code). |
Link test |
Once the link is activated, it is used to verify that a connection is possible (the attempt is made to open one of the supervisor tables).
|
Link deactivation |
This function deactivates the link, that is:
|
By default, the following reports are associated with this function:
This can be changed using a different setup.
Save |
This button launches the function to validate the folder. In the dedicated Technical appendix you can found the detail of the operations carried out when validating the folder. |
This function is particularly useful at the time of the transfer of a complete folder from one folder to another. It is necessary on one hand to transfer the file directory structure of a folder and on the other, to transfer the data (this can be done using the database tools or by safe x3 table import/export if the target folder already exists). But it is also necessary to recuperate the structure information contained in the Folder record (in effect, the information in this record are stored in the ADOSPAR, ADOSIM, ADOSACT tables, which are the supervisor tables attached to the supervisor folder, and therefore not automatically transferred. Import option allow the creation of a correct Folder record, in reading the configuration record called PARAM.ini, located in the root directory of the transferred folder. The PARAM.ini record, created at the time of the creation of a folder, is updated at each revalidation. |
This function is used to view the log file relating to the last validation carried out on a folder. It is important to review this log file when the validation is finished, in order to verify that there have been no errors. The errors are in red for identification in the log file. |
This function starts the size calculation taking into account the sizing parameters defined in the corresponding tab. When the function has been executed, a window allows the appearance in a grid, for each table, the number of lines calculated and the size in Mega-bytes necessary for the data and for the indexes. At the bottom of the window, the cumulated size for the data and for the indexes is displayed, as well as the total size necessary. This size can be copied to (with a possible increase) to the first section in Folder management. The format of the database is of course taken into account when determining the proposed size in mega-bytes. The algorithm is the following:
|
This function is used to import the file "BATCH.tmp" present in the basis directory of the GDOSX3 folder. This import overwrites all records present in this file. For recurring tasks, the parameters are not reused and all recurring tasks are disabled during import. At the end of the import, the file BATCH.tmp is deleted. This function can only be accessed from the root folder GDOSX3. |
This function is used to create a setup file for the BATCH server in order to reuse them in another folder and another version. The following elements are exported:
This function creates a file named BATCH.tmp in the basis directory of the GDOSX3 folder. All records superior to X are also reused. This function can only be accessed from the root folder GDOSX3. |
In addition to the generic error messages, the following messages can appear during the entry:
The name of the volume (A by default) is not known.
In the language table, a language code has been entered that is already referenced in a previous line.
An attempt is being made to start folder revalidation, but users are still connected to the folder.
When the folder validation is started, a log file is created. A series of errors can occur. They appear in the form of an error line (in red) in the log file, followed by additional information. Certain errors are generic, but most are linked to the complex phase of screen revalidation. The two series of errors are listed below.
You can access the folder validation log file by clicking Log from the folder management. If the validation of a folder is launched by the batch server, the query log file will only give the validation launch time: to view the detailed log of the operation, it is necessary to use the folder management.
Other errors not listed are likely to occur, in particularly at version change. These errors are defined in the release notes accompanying the version updates.
These errors can arrive in the preliminary phase of blocking a folder in the process of revalidation, blocking not being possible at this time.
A problem with access rights exists in a table whose name is given in the following message. These errors can arrive in any of the generation phases (screen creation, menus....) if an access problem exists in one of the corresponding dictionary tables.
When validating a screen, there is not sufficient space to position all the fields in a screen (this does not prevent the validation of the screen, but it is necessary to manually verify the screen).
These non-blocking errors can occur when validating a screen: they cannot occur on entered screens but could occur after the transfer by interfolder copy of elements, followed by a folder revalidation. In that case, a manual control must be performed.
These blocking errors can occur when validating a screen: they cannot occur on entered screens but could occur after the transfer by interfolder copy of elements, followed by a folder revalidation. In that case, a manual control must be performed.
The variable at the bottom of the block has not been correctly declared in a section structure.
The volumes are used to define the directories where the software installation files and the files concerning the created folders (excluding the database) are located.
These directories are defined in a configuration file named adxvolumes, installed in the engine installation root directory (this directory being itself identified by the volume 0 (zero), which is reserved for the installation of the run-time engine).
The database path of a volume can be found by using the following function in the SAFE X3 calculator:
filpath("!","","","","x")
where x is the volume code (0, A,B,C...)
By assigning the second parameter of the filpath function, it is possible to find the exact access path to the adxvolumes file itself:
filpath("!","adxvolumes","","","0")
In the standard installation, the adxvolumes file contains at least two lines (one of the lines for the 0 volume, the other for the A volume, possible others for the B, C, D (etc.) volumes) in the following format (on a NT server, on a UNIX server, the paths are in the format /home/SAFEX3/runtime, for example):
0:D:\SAFEX3\Runtime
A:D\SAFEX3\Folders
B:E:\VolumeB
Using more than these two folders may not be very useful as folder structures with a lot of files more or less take the same amount of space: it is not necessary to distribute the data over various disks for optimization (the data is in the database). The only case where this could be interesting is the one where the text and image files are stored in the TXT directory as it was done previous versions. In addition, when using the Web interface, the XML files generated and used by the HTTP server are always stored in a directory defined in the volume where the Supervisor folder is installed (usually A).
Various types of modules can be defined:
Interdependence constraints exist between modules. These constraints are directly tested when entering active modules and are described in the Appendix documentation. For technical modules, the Supervisor and Common data must be set to Yes.
Refer to documentation Implementation
