Folders
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:
- a root directory and a group of sub-directories on the application server. The SAFE X3 objects arising out of the parameters can be found there.
- an Oracle user (or a user combination, login with SQL server) defined for the database server. All the database tables are attached to it.
Folder creation/copy
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.
Prerequisites
Refer to documentation Implementation
Screen management
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.
Home
Presentation
A folder is defined by an alphanumeric code of over 10 characters, to which a set of parameters defined on tabs is linked.
Close
Fields
The following fields are present on this tab :
| The name of the folder can take a maximum of 10 alphanumeric characters. The first letter must be alphanumeric. |
| Enter the description of the relevant record. This long description is used as a title in screens and reports. |
Close
Tab General
Presentation
Use this section to define the main organizational information for folder definition.
Close
Fields
The following fields are present on this tab :
Database
| 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. |
| 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 key. Please refer to the technical appendix on Volumes at the end of the Folder management documentation. |
SQL server
|
|
| 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). |
Base sizing
| 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). |
|
|
| Defines the set of characters used to store the character fields in the database. It can take the values ASCIIor 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. |
Folder type
| 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. |
| 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). |
| 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. |
| 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. |
| 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. |
| 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. |
| 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. |
Grid Installed modules
|
|
| 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. |
Sizing
| 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). |
|
|
| 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). |
|
|
Close
Tab Setup kits
Fields
The following fields are present on this tab :
Grid Options
| An activity code is used to:
If the activity code is disabled:
|
| Title associated with the previous code. |
| Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
| 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:
|
Grid Localizations
| An activity code is used to:
If the activity code is disabled:
|
| Title associated with the previous code. |
| Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
| 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:
|
Action icon
Tab Options
Presentation
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:
- the first table, named Options, contains the general interest activity codes.
- the second table includes the Localization activity code. These codes starting with a K, define the management options used for local localizations.
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.
Close
Fields
The following fields are present on this tab :
Grid Functional sizing
| An activity code is used to:
If the activity code is disabled:
|
| Title associated with the previous code. |
| Module to which the activity code is attached. If the module is not active, the activity code will not appear in this grid. |
| 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 theSizing type. |
| 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. |
| Define the maximum possible dimension taken into account in the table structures in the database. |
Close
Action icon
Tab Screens
Presentation
In this tab, a single table appears. It contains the activity codes of two types, which are related to:
- the sizing of grids in the screens of the software (indeed, the screens which are used to enter multi-line documents are sized statically upon entry of a function).
- the sizing of some values that are stored randomly in the database. In this case, there are normally few values (less than a hundred).
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.
Close
Fields
The following fields are present on this tab :
Grid Table sizing
| 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. |
|
|
| 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. |
| This number corresponds to the value linked to the sizing element of the line. |
Close
Action icon
Help
Is used to access the help defining the aim of the sizing variable, the values it can have and the impacted functions.
Close
Tab Tables
Presentation
This section is used to enter information that will be used by a sizing algorithm to calculate:
for each database table, a physical storage size is estimated. This physical size is used during the definition of the table characteristics (planned size, extents management in Oracle, for example).
by cumulative, the global size of the database
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.
Close
Fields
The following fields are present on this tab :
Grid Transaction validation
| 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. |
| A positive response to the question leads to the validation of the transactions associated with the module. |
Grid Languages
| 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. |
| 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 :
|
Grid Legislation
|
|
Grid Copy data
| 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. |
| 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 values
| 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. |
| 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. |
| 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. |
Update
| 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). |
|
|
|
|
|
|
Close
Action icon
Tab Initialize
Presentation
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 copy options are used to enter the data of some tables from the table content of another folder (the copy folder declared in the first tab, the default reference folder). This is made upon folder creation or upon revalidation if a module addition activates the table that were not used yet. The renaming screen makes it possible to rename the codes created by these copy options.
- The grid Validation of transactions is used to prevent all screens that can be set up to be revalidated from the base screen (in the parameters menu in all modules) upon revalidation of a folder. Since the revalidation may take time and is not necessary if the structure of the base screens has not changed, it can be avoided by answering No to the question. When answering No by mistake or avoiding the folder revalidation time on purpose, it is still possible to relaunch the validation via the dedicated function.
- The Update check boxes are used to avoid the code regeneration associated to the revalidation of a certain number of elements in the dictionary upon folder revalidation. This is done in order to shorten the revalidation time. For security reasons, these boxes can only be unchecked in a development folder, and it must be done with caution. This can also be done later on via a dedicated function.
- The language table makes it possible to define a list of languages that can be used by users connected to the folder. It is advisable to only select those that are actually useful, because this slows down the folder creation (part of the files linked to the windows are generated for each language retained).
Close
Fields
The following fields are present on this tab :
Grid Transaction validation
| 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. |
| A positive response to the question leads to the validation of the transactions associated with the module. |
Grid Languages
| 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. |
| 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 :
|
Grid Legislation
|
|
Grid Copy data
| 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. |
| 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 values
| 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. |
| 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. |
| 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. |
Update
| 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). |
|
|
|
|
|
|
Close
Action icon
Tab Specific
Presentation
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.
Close
Fields
The following fields are present on this tab :
Grid
| Defines the custom/specific activity codes (i.e. starting with X, Y, or Z), which can be activated in the folder. |
| Title associated with the previous code. |
| 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. |
| If this field is set to Yes, the fields marked by the activity code in the dictionary are activated. |
| 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. |
| 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. |
Close
Tab Miscellaneous
Presentation
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.
Close
Fields
The following fields are present on this tab :
System
| 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. |
|
|
| This field is used to define the memory size allocated to the process accessing the database (it is named sadoraor sadossaccording 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. |
|
|
| 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. |
|
|
| 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. |
|
|
| 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. |
|
|
|
|
|
Close
Action icon
Tab Links
Presentation
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:service@DOSSIER2.TABLE"
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.
Close
Fields
The following fields are present on this tab :
Connection
| This field, display only, corresponds to the code for the folder being worked on. |
| 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). |
| Defines the TCP/IP port in which the connection server expects the connection requests from the folder. |
| 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 :
|
| 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. |
| 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. |
Grid Access rights to the folder
|
|
|
|
Grid Folder links outside of solution
| Defines the type of link:
|
| 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. |
| Network path defining the remote server to be connected to. |
| Number of the remote server to which a connection is made. |
| 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. |
| Defines the operating system of the server to which the link is made. |
| Define the linked folder to be connected to. This information is mandatory when the link is characterized, but not for a miscellaneous link. |
| 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). |
| Define the database type to which the user is to be connected. |
| 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. |
| 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). |
| Defines the user code (in the database sense) used for the connection. |
| Defines the password (in the database sense) for the user to be used to connect to the remote database. |
| This is the platform used by the Bridge Java to open a remote session. |
| This is the password of the User platform used by the Bridge Java to open a remote session. |
Close
Action icon
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).
This function is only available if the folder whose links are being set up is the current folder.
Link deactivation
This function deactivates the link, that is:
- the Active check box is updated in the folder parameters.
- suggests to delete the directory and the files created upon link activation, if this link does not correspond to a ‘true’ remote folder. Caution: deleting this directory triggers the deactivation of the connection possibilities for folders with the same name located on other servers. The answer to the proposition is thus not compulsorily Yes.
Close
Reports
By default, the following reports are associated with this function :
ADOSSIER : Folder parameters
This can be changed using a different setup.
Specific actions
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. |
Actions menu
Options / Import
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.
Options / Log
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.
Options / Size
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 :
- in an ASCII database type, one character accounts for one byte.
- for a UNICODE database type (UTF8 or UCS2), the character accounts for 2 bytes, except if the environment variable named STUSIZE (it can be read by the SAFE X3 function getenv$) exists, to give a different multiplication coefficient. In the case of a database managed with Chinese characters, for example, it is advised that the value is set to 3 rather than 2, but it can be an intermediate number such as 2.5.