Import job properties: Options
Contents
On the Options tab, which is present when you have opened a new or existing import job in the Import job editor, you specify the basic options for the current import job.
Click here for information on how to edit job properties in general.
On the current tab you'll find the following settings:
While importing, Designer can check whether a record already occurs in the database and update it; only tags specified in the tag pair list (field mapping) of this import job, will be updated. To do this, the program has to know by which field each record must be identified, preferably a unique field (e.g. a record number field). You can search for the desired (indexed) field in the destination database table or dataset by clicking the ... button. The field you choose must also be included in the field mapping.
If you leave this field empty, Designer will not check whether records already exist. The records in the import file will simply be added to the database. If you leave the Ignore priref property unmarked too, the imported records will be given the same prirefs (record numbers) as they had in the exchange file. Any existing records with the same priref will then be completely overwritten!
If you fill in %0 (= primary reference) for the Update field property, Designer will check whether each specified priref in the exchange file already exists in the database table. If so, the existing record will be overwritten ("updated" as it were), as far as specified in the tag pair list of this import job. If you have left the Delete data in existing records property (see below) set to No, then tags already present in the existing record will be kept intact, provided they don’t occur in the exchange file: so tags (and their contents) in the database table will only be replaced if they are in the exchange file too (and in the tag pair list of course). Note that setting the Delete data in existing records property to anything else but No, is the only way to empty fields during the update: with the option set to No, an empty field value in the exchange file will not replace any existing field value in the record!
If you enter another tag for this field than the priref, there must be a text (term) index for the field. (Although preferred, this index need not be unique: if it isn't unique, the import will only update the first indexed record with the non-unique term.) Designer will check whether the specified tag value (the contents of the tag) in the exchange file already exists in the database. If so, the corresponding record(s) will be overwritten. If you have set the Delete data in existing records property to No, tags in the existing record(s) will remain, provided they don’t occur in the import file record.
If you import into a dataset, instead of into the entire database table, records will only be updated if they are part of that dataset (even if the search for records to update would find a matching record in another dataset, which is possible because the index on the update tag spans the whole database table).
You can further specify the updating of target records, pertaining to occurrences of tags, by setting the Update option on the Mapping tab to Append or Append if not present.
Please note that Designer will only add records (as in: enlarging the total number of records in the dataset) if you have marked the Add new records property (see below) for the above situations (where Update tag is filled in). If you deselect this property, records, or parts of them, can only be replaced.
If the update field is a multilingual field, all translations of the present data will be checked for the update value, unless you use the Update language option (see below) to have the software check only one of the translations. By default, the software first checks all records in a language 1, then all records in a language 2, etc. If the update value is found, the record will be updated.
From Designer 6.5.1, you can use a multilingual field as the update tag in an import job, and specify a language in which to search. If the relevant field from the exchange file is multilingual too, only the value from the Update language will be used to search on. If you do not specify a language for a multi-lingual field, all language values of the update tag will be searched. The other way around, a specified language for a unilingual field (without language attribute) will be ignored: the update field will be used normally, as if you hadn't specified an update language.
The Update language is optional, but when used it should be filled with a standard language code*. You can use this option with all exchange file formats.
* The language code is a code put together from an abbreviation for a language and a region identifier (for more information about this, see the “Using Language Identifiers (RFC 3066)” document which you can find on the internet).
If you have entered a value for Update field, you can also decide whether it will be possible to add new records too, instead of only replacing records. Mark this option if you do want adding to be possible.
Delete data in existing records
If you have filled in a value for Update field, you can also specify which tags must be deleted when a record is updated. You can choose from three settings:
| • | No - All tags from the exchange file record (if specified in the mapping) replace any existing, unilingual tags; all other existing tags remain intact. Of multilingual destination tags, existing language values will only be overwritten if the exchange file record contains a mapped value (empty values won't be mapped) for that data language: other language values in the destination tags will remain intact. |
| • | Yes, delete all fields - All occurrences of all fields (in all data languages, if present) in the destination record will be deleted, after which all tags from the exchange file record (if specified in the mapping) will be imported into the record. |
| • | Yes, only mapped fields - The first occurrence of all mapped fields (for multilingual fields in the specified Default language or in all data languages if no Default language was specified) will be deleted, after which all tags from the exchange file record (if specified in the mapping) will be added to the record; all other existing tags will remain intact. If you've mapped ** to **, you've mapped all fields, so all fields will then be deleted before any tags are imported. |
You can use this property to specify whether Designer is to automatically update external links to linked records. An external link is a link from a record in the current database table to a record in another database table (like the link to a name record in the PEOPLE database table, from within the Author field of a book title record in the DOCUMENT database table), while an internal link is a link from a record in the current database table to another record in the current database table (like you have in the Thesaurus, for instance), as defined under the Internal links node in the database tree in the Application browser.
Mark this checkbox, and for a linked field it will be checked whether the imported field value occurs in the linked-to field anywhere in the linked database table. If not, a linked record for that value does not exist yet, and a new record for that value will be created in the linked database table (and the record number of the new linked record will be retrieved - this is called resolving - and imported into the linkref tag of the linked field in the target database table). That means that the Allow creation of new linked records property of these linked fields in the database setup, must be set to true, or that you must set Forcing always allowed in this import job (see below). If the field value does already occur in the linked-to field in the linked database table, the record number of the relevant linked record will be resolved and imported into the linkref tag of the linked field in the target database table.
If you unmark the Process external links option, linked fields and their values, and/or link reference tags and the record numbers they contain, will be imported, but during this import there will be no check whether the linked records for any imported field values actually exist. This means that if this destination field has a link reference tag, this tag will remain empty (if it was empty in the exchange file) while the linked field is filled, or the linkref tag will be filled with the record number from the exchange file (which may or may not be correct: without resolving you cannot always be sure of this). Note that any faulty link reference tags cause problems in your data and indexes, while missing link reference tags may cause errors if you try to export them again.
Any non-preferred terms in the exchange file will be substituted by the defined preferred terms during import for all externally linked fields in the primary destination database, if Process links is marked.
Note that from Designer 6.5.1, the previous Process links option has been split up in the two options Process external links and Process internal links, to be able to separate the processing of links. This can result in faster importing if the processing of one of both types of links is not required. Normally though, you would mark both options.
In the overview below, all export/import combinations pertaining to links processing are explicated. To keep the text as straight forward as possible, we assume here that simply all tags are included in the field mapping of the import job; but consider that for linked fields it is good not to include merge field tags if you process links during import, because including those tags would store their values in the target fields. Yet, actual merged-in field values in the target database table will automatically be retrieved from the linked record later whenever a record is opened, while those values won't be stored in the destination fields. So, excluding merged-in field tags from the import job (with links processing on) keeps their counterparts in the target database table empty (as they should be), and makes your import faster.
Export - links processing option |
Import with external links processing on/off |
Export with links: only linked field values
Of linked fields, this will export any linked data to the exchange file, meaning the tag of the linked field (in the primary database table) and its resolved contents: the field value copied from the linked record, and also merged tags defined for this linked field, and their contents.
|
On: of linked fields, the field values will be imported and resolved, so that the linkref tags in the target database table will be filled with actual record numbers of the linked records.
|
Off: of linked fields, only the field values will be imported. The software will not resolve the linked field values, meaning: it won't look up those values in the linked database table to retrieve the record numbers of those linked values, so you won't be sure if linked records actually exist for the imported values, and the linkref tag of the linked field will remain empty; and because of the empty linkref tag, the linked field value will not be indexed, so you won't be able to search on this value afterwards via its index/access point.
|
|
Export full record: field values plus linkrefs
This option does the same as Export with links, but adds the forward reference tag and its content: the record number of the linked record that holds the field value for this field. |
On: of linked fields, the field values will be imported and resolved, so that the linkref tags in the target database table will be filled with actual record numbers of the linked records, and these record numbers are not necessarily the same as the record numbers in the linkref tags in the exchange file. The linkref values from the exchange file won't be imported into the target database table at all.
|
Off: of linked fields, the field values and the associated record numbers of those linked records (in the linkref tags) will be imported. The software will not resolve the linked field values, meaning: it won't check whether the imported linked record numbers are correct, so it is possible that corrupt links will be created.
|
|
Export without links: only linkrefs
Of linked fields, this will only export a reference to linked data, meaning the forward reference tag and its content: the record number of the linked record that holds the field value for this field. |
On: no linked field values and no linkrefs will be imported. A linked field value is required for resolving the link (retrieving the relevant record number); since a linked field value is not present in the exchange file, there is no way to validate the record number from the linkref tag in the exchange file, so the linkref tag in the target database table will remain empty.
|
Off: of linked fields, only linkrefs will be imported. Since the software won't try to resolve the link, the record number in the linkref tag will just be imported into the linkref tag in the target database.
|
The general rule of thumb is that if you exported data with links processing on, then you should also import that data with links processing on. And the reverse is also true: if you exported data with links processing off, then you should also import that data with links processing off.
You can use this property to specify whether Designer is to automatically update internal links to linked records, for the imported record. An internal link is a link from a record in the current database table to another record in the current database table (like you have in the Thesaurus, for instance), as defined under the Internal links node in the database tree in the Application browser, while an external link is a link from a record in the current database table to a record in another database table (like the link to a name record in the PEOPLE database table, from within the Author field of a book title record in the DOCUMENT database table).
Mark this checkbox, and for a linked field it will be checked whether the imported field value occurs in the linked-to field anywhere in the current database table. If not, a linked record for that value does not exist yet, and a new record for that value will be created in the current database table (and the record number of the new linked record will be retrieved - this is called resolving - and imported into the linkref tag of the linked field in the current database table). That means that the Allow creation of new linked records property of these linked fields in the database table setup, must be set to true, or that you must set Forcing always allowed in this import job (see below). If the field value does already occur in the linked-to field in the current database table, the record number of the relevant linked record will be resolved and imported into the linkref tag of the linked field in the current database table.
Since internal links may define preferred term relations, of course no non-preferred term substitution will take place during import.
The selected Process internal links option applies only to the imported records, not to any FACS records written or updated using an adapl associated with this import job: you'll then have to program the adapl so that both sides of an internal link will be written explicitly.
If you deselect the Process internal links option, linked fields and their values, and/or link reference tags and the record numbers they contain, will be imported, but during this import there will be no check whether the linked records for any imported field values actually exist. This means that if this destination field has a link reference tag, this tag will remain empty (if it was empty in the exchange file) while the linked field is filled, or the linkref tag will be filled with the record number from the exchange file (which may or may not be correct: without resolving you cannot always be sure of this). Note that any faulty link reference tags cause problems in your data and indexes, while missing link reference tags may cause errors if you try to export them again.
Note that from Designer 6.5.1, the previous Process links option has been split up in the two options Process external links and Process internal links, to be able to separate the processing of links. This can result in faster importing if the processing of one of both types of links is not required. Normally though, you would mark both options.
In the overview below, all export/import combinations pertaining to links processing are explicated. To keep the text as straight forward as possible, we assume here that simply all tags are included in the field mapping of the import job; but consider that for linked fields it is good not to include merge field tags if you process links during import, because including those tags would store their values in the target fields. Yet, actual merged-in field values in the target database table will automatically be retrieved from the linked record later whenever a record is opened, while those values won't be stored in the destination fields. So, excluding merged-in field tags from the import job (with links processing on) keeps their counterparts in the target database table empty (as they should be), and makes your import faster.
Export - links processing option |
Import with internal links processing on/off |
Export with links: only linked field values
Of linked fields, this will export any linked data to the exchange file, meaning the tag of the linked field (in the current database table) and its resolved contents: the field value copied from the linked record, and also merged tags defined for this linked field, and their contents.
|
On: of linked fields, the field values will be imported and resolved, so that the linkref tags (if present) in the target database table will be filled with actual record numbers of the linked records.
|
Off: of linked fields, only the field values will be imported. The software will not resolve the linked field values, meaning: it won't look up those values in the current database table to retrieve the record numbers of those linked values, so you won't be sure if linked records actually exist for the imported values. If the linked field has a linkref tag, it will remain empty, and because of that the linked field value will not be indexed, so you won't be able to search on this value afterwards via its index/access point. If, on the other hand, the linked field has no linkref tag, as is often the case in applications older than version 4.2, the linked field value will be indexed normally.
|
|
Export full record: field values plus linkrefs
This option does the same as Export with links, but adds the forward reference tag and its content (if present): the record number of the linked record that holds the field value for this field. Note that internally linked fields in applications older than version 4.2 often have no link reference tags. |
On: of linked fields, the field values will be imported and resolved, so that the linkref tags (if present) in the target database table will be filled with actual record numbers of the linked records, and these record numbers are not necessarily the same as the record numbers in the linkref tags in the exchange file. The linkref values from the exchange file won't be imported into the target database table at all.
|
Off: of linked fields, the field values and any associated record numbers of those linked records (in the linkref tags, if present) will be imported. The software will not resolve the linked field values, meaning: it won't check whether any imported linked record numbers are correct, so it is possible that corrupt links and index entries will be created.
|
|
Export without links: only linkrefs
Of linked fields, this will only export a reference to linked data, meaning the forward reference tag and its content: the record number of the linked record that holds the field value for this field. Note that internally linked fields in applications older than version 4.2 often have no link reference tags. |
On: no linked field values and no linkrefs will be imported. A linked field value is required for resolving the link (retrieving the relevant record number); since a linked field value is not present in the exchange file, there is no way to validate the record number from the linkref tag in the exchange file, so the linkref tag in the target database table will remain empty.
|
Off: of linked fields, only linkrefs (if present) will be imported. Since the software won't try to resolve the link, the record number in the linkref tag will just be imported into the linkref tag in the target database table.
|
The general rule of thumb is that if you exported data with links processing on, then you should also import that data with links processing on. And the reverse is also true: if you exported data with links processing off, then you should also import that data with links processing off.
For the rare occasion in which you are importing into a specific dataset (not the entire database table) and you are using an update tag which has a non-unique index while that tag is part of an internal link definition for which the Database scope has been set to Database, then you will run into problems when duplicate keys pertaining to records in other datasets exist in the index (producing an import error 157 for every record that can't be updated because it's not located in the import target dataset). Since there's probably a good reason why the database scope has been set to Database, for instance because links between the internal and external objects are allowed, you cannot just change the database scope to Dataset, even as a temporary setting to run the import, because what you would need in this case is the ability to select multiple datasets or a compound dataset as the scope. Since this option doesn't exist, you may have to do without the Internal links processing option and write the relevant internal links by means of an import adapl.
You can use this option to determine whether Designer must clear the target database table before importing the exchange file. So, if this option is marked, then the entire database table will be emptied! Note that the pointer file (aka saved searches) tables will not be emptied: if you want to remove pointer files, you must do so by deleting them from within your running Collections application.
If you mark this option, records will be forced into a linked database table, regardless of how the Allow creation of new linked records property of any linked fields in the target database table has been set. For this, the Process links import job option (see above) must, of course, be selected. This option also applies to values written by an associated import adapl into a linked field in a FACS database: that will create an appropriate linked record as well, if it doesn't exist yet.
If you leave this option deselected, then the setting of the Allow creation of new linked records property of a linked field into which a new value is imported, will determine if the value will be forced as a record in the linked database table.
Always create new domain records
Before Designer 7.2, when you used Axiell Designer to import an existing term into a linked field with a fixed domain other than any domain already associated with the term registered in its authority database table, the new domain would automatically be added to the existing term record.
This is not always what you want though. Sometimes you would like to have the option to force a new linked term record for the identical term* and have the new domain associated with the new term record only. For instance, suppose you have an existing authority record for the term “bank” with the associated domain “furniture”. Now, if you were to import or enter the term “bank” in a linked field with the fixed domain “financial institution”, you would surely want to create a new linked “bank” record with the “financial institution” domain, instead of linking to the existing “bank” record associated with two different domains. This option has become available in Axiell Designer 7.2.
Mark the Always create new domain records checkbox to make sure that whenever an existing term is imported into a linked field with a domain different from the domain(s) for the already present term record, a new linked record will be created for that term, with the new associated domain. For an existing term without domain, the imported term will also be stored in a new record.
Note that the ability to create new records also depends on the Forcing always allowed and Process links options on the current properties tab.
* Duplicate terms in authority data sources like the Thesaurus or Persons and institutions are only allowed if the indexes on the relevant fields can index non-unique keys as well. Typically this is the case when the internal links in these database tables in your application are linked on reference (record number), not on value (although indexes on reference-linked internal links may still have been set to unique). By default, internal links on reference have only been implemented in our model applications 4.2 and higher. Further, the current option to have duplicate term records created, is offered regardless of whether indexes are indeed non-unique: if they are unique, regular error messages will inform you that the entered or imported term has to be unique.
If a database table is divided up into datasets, then the record numbers (prirefs) determine in which dataset records belong (since every dataset consists of database records in a specified range of record numbers).
If you instruct designer to ignore prirefs from records it imports (mark this option), then the program will assign new prirefs itself, starting from the lower limit record number of the dataset into which the data is imported if this dataset is empty. However, if there already exist records in the dataset into which you are importing, then new record numbers will follow the highest existing record number. And if during import the dataset record number upper limit is reached, the software will search for any free record numbers from the lower limit of the dataset.
If you leave this option unmarked, the imported records will be saved with their record numbers from the exchange file, and overwrite any existing records with those numbers; importing might then also occur outside the target dataset range, depending on the record numbers in the exchange file.
Enter a value to instruct Designer how often it must provide you with information about the progress of the import operation. For example, with the value 100, this happens every 100 records (which setting is advisable for large import jobs). A larger value will speed up the import process somewhat.
Here you specify which ADAPL procedure (if any) Designer must carry out after reading in a record from the exchange file and having completed the field mapping, but before any update process has been set in motion (if the Update tag option has been set) and thus also before writing the record to the target database table. This option is available from Designer 7.2.14286.3.
So the after-read adapl will be executed before any update process. This means that if you have set an Update tag for the import job, this adapl will be executed before the import procedure uses the update tag to search for an existing target record to update. You can use this fact particularly to preprocess the value which will end up in that update tag, an object number for instance. This may be necessary if the relevant data (object numbers in this example) in the exchange file has a different form than that data in the target records. Sometimes the source data may contain field data from which object numbers have to be extracted first, because there’s other data in the field too, or it is necessary to put object numbers together from data from multiple fields in the exchange file before they match object numbers in the existing target records. You can use the after-read adapl to actually do that processing. This adapl can in principle be programmed in the same way as the Storage adapl for an import job.
The after-read adapl will be executed with execution code 27, that is to say: &1=27. Click here for more information about execution codes.
Here you specify which ADAPL procedure (if any) Designer must carry out after reading a record from the exchange file, having completed the field mapping and possibly having found any target record to update (if the Update tag option has been set), but before writing it to the target database table. This import adapl is not carried out for linked records that are created during importing.
A Storage procedure that may be linked to the database table is never carried out during the import with Designer.
For the programmatic design of an import adapl, you should take the following into consideration:
| • | you can use the ERRORM statement, but whenever this statement is executed during import, the message will be written to an error log file (in the folder containing the import job) with a name formatted like <importjob_name>.imp.err, and won't be displayed on screen. |
| • | The adapl will be executed per record, after the field mapping has been applied. This means that in your adapl you will have to use the target field tags to request the contents of fields from the exchange file. |
| • | You can write to the target tags as well. The field definitions in the target database table do apply, so you can't write to a second occurrence of a field tag if that field is not repeatable. This applies to all tags in the target database table, not just the ones mapped from the exchange file. You can write a value to a specific language of a multilingual field, via the syntax: <tag>[<occ>, 'language code'] = <tag or value>, for example: te[1, 'en-US'] = te[1, 'en-GB'] to address the English-US attribute of the first occurrence of a multilingual Term field and copy to it the value from the already mapped first English-Great-Britain Term field occurrence. The occurrence number is mandatory. If you also want to make the target language the invariant language, you can do so by inserting a hash character in front of the target language code, for example: BA[1, '#fr-FR'] = BA[1, 'fr-FR'] to set the French language value as the invariant one. If mono-lingual (without language attribute) data from the exchange file all needs to be assigned the same language attribute in the target database table, a more efficient solution is to use the Default language option (and possibly the Make this the invariant language option as well) below: no need to program that in an adapl. |
| • | If you'd like to know if a field does not appear in the exchange file or is empty in the exchange file - you cannot separate these situations - then use if (tA = '') {...} in which you replace tA by the actual tag. |
| • | You can use FACS to read and write in other database tables than the target database table, or to read the target database table to get the current (old) saved state of the record which the import procedure is currently about to update (because you'd like to compare the old and new data, for example). Do take into account that a single-sided FACS write of an internal link or reverse link will not automatically create the reciprocal links, so the adapl has to write the appropriate link references on both sides of the link explicitly. |
| • | To get the process links options to do their work in the currently imported record, remember to import values into the linked field itself, not record numbers into the link reference field of those linked fields. If it isn't important that links are processed in the currently imported record you can of course enter record numbers in the link reference fields if you wish. |
| • | Use the VAL function to convert numbers appearing in tags (even temporary ones) from text strings to numerical values if you want to perform some calculation with those numbers. This is even true after an assignment, so if you write ab = 10 (where in this case ab is a tag not an integer variable), then if you'd like to compare that value to another literal integer you'd have to write something like if (int(val(ab)) > 5) { ... }. This does not apply to integer or numerical variables. |
| • | Watch out for enumerative fields too. You'll have to import or write a neutral value into such a field, but when you retrieve a value from such a field (even if you just mapped it or assigned its value) you'll have to use the enumcode$(<tag>[occ]) function to retrieve that neutral value again, if you want to compare it to a literal string, for example. |
| • | Data dictionary field group functionality like adding or sorting group occurrences, with the exception of REPCNT, is switched off during import of data. |
| • | You can use select no to stop a record from being imported. |
In Axiell Designer versions older than 7.1, adapls which have been compiled in debug mode can only be used as ADAPL procedure here if you execute this import job with import.exe: these versions of Axiell Designer did not support adapl debugging during import. From Designer 7.1 though, adapls which have been compiled in debug mode are supported as ADAPL procedure here by both import.exe and the Axiell Designer import functionality.
One of the possible authorisation mechanisms for a database table in Collections is the Authorisation type called Rights. With the Rights method, the initial creator of a record, the so-called Record owner, always has full access to that record, and it is this creator and he or she alone that is allowed in this record to set and change which users have which access rights, or transfer the record to another record owner. The user name of the creator of a record will be stored automatically; this name is determined through the login of the current user.
If this type of authorisation has been implemented in the target database table into which you are about to import your exchange file, you may need a way to set the record owner name for newly created records without a current record owner, since the software would otherwise make the person who does the importing the record owner of the new records. You can do this with the current option: just enter the (login) name of the intended record owner of newly created records in the target database table, which do not have a record owner in the exchange file. Records in the exchange file which already have a record owner will not be assigned the new record owner, nor will in the target database table existing records with a record owner be assigned the new record owner, if those existing records are only updated during the import - so the record owner tag won't be updated.
If newly created records without a current record owner should remain without record owner, then literally enter <null> for the current option.
Leave this option empty if the target database table has no Record owner field.
If the Default access rights property of the database table has been set to None or Read you can still import records into this database table, using Axiell Designer or import.exe, but you cannot import records that link hierarchically or reversely to an existing record or have imported records force new linked records automatically, because for the latter actions the access rights mechanism of the application becomes active and since Designer and import.exe have no knowledge of user names and roles specified in the application, the $REST role is assumed instead of the proper role of the user who is doing the import (who should have at least write access).
To allow for a successful import in such circumstances anyway, the role entered in the current Record owner option of an import job will also be the role with which the import job will be carried out by Designer 7.7.19345.2 or import.exe 7.619345.3 and higher versions. So you should now use an import job Record owner with Full or Write access to the relevant database table. If you don't want this record owner to end up in the Owner field in imported records too, you can still use an import job Storage adapl to empty the Owner field again.
The setup of this type of authorisation can be found on the Database properties tab of a database table, where a Record owner field is implemented for the Authorisation type: Rights. Authorisation fields must also be present on detail screens.
From 6.5.1, this Default language option and the Language option on the Mapping tab provide a way to specify the language attribute (using a standard language code*) with which an imported value (originally without language attribute) has to be stored in a multilingual target field, during import. With the current option you specify this language for all multilingual fields in the target database table together, while the Language option on the Mapping tab allows you to specify that language per mapped field.
Use the current option if your exchange file contains values in only one (non-explicit) language; then you do not have to specify a language for every multilingual target field in your field mapping separately. Just set the desired target language of all multilingual fields at once in the Default language option. (By the way, no invariancy flag will be added to this data language, unless you check the Make this the invariant language option below.)
If you use neither option, values will be added to multilingual fields without any language attribute; however, when a record with a multilingual field is written again, by editing and saving it, Collections will check if the field already has a data language attribute and if not, it will add the active data language as the attribute.
For multilingual fields in AdlibXML type exchange files, the Default language and field mapping Language setting do not apply. This is because AdlibXML contains a language attribute per multilingual field value. When you import a record with multilingual fields, all multilingual values from the exchange file will automatically be copied to the target database table, thereby leaving other, existing multilingual values intact. So, if a source field were to hold three values in the Dutch, English and French languages, and the target field would hold two values in the Dutch and Greek language, then the Dutch value would be overwritten, the Greek value would remain intact, and the English and French values would be added. Any existing invariancy flags will be imported too.
Both language options, plus the Make this the invariant language option, do apply for all mono-lingual fields (without a language attribute) in AdlibXML type exchange files; and these options always apply if your exchange file is of the (Adlib) Tagged type, because that is mono-lingual by definition.
Any default language you set here, will also be used by an import adapl whenever the ADAPL code assigns a value to the tag of a multilingual field without specifying the language to write to. If you do specify the target language in the value assignment, it will override the default language.
* The language code is a code put together from an abbreviation for a language and a region identifier (for more information about this, see the “Using Language Identifiers (RFC 3066)” document which you can find on the internet). The code for British English, for example, is en-GB.
Make this the invariant language
Make the Default language the invariant language by marking this checkbox. Prior to Designer 7.1, you could only add the invariancy flag manually when editing a record, per multilingual field, via the Edit multilingual texts window (to be opened by right-clicking the field) or you could import multilingual AdlibXML exchange files including any invariancy flags already present in the data.
The (optional) invariancy flag for a value in a particular language allows the user to see this value in all other data languages of the field as well (as long as it’s empty), to ease translation or to always have data present in the field, even if it concerns data in the wrong language.
Import jobs with the Make this the invariant language option can also be run by the 7.1 version (or higher) of import.exe.