The purpose of the command-line IndexCheck tool is to check whether indexes are correct, by reading all records again and comparing the current contents of the index to what is supposed to be indexed. If wrong keys appear in the current index, or if values from records are still missing in it, IndexCheck can automatically perform repairs to yield a correct index. (This of course asummes that IndexCheck is flawless in this respect.) To be more precise:
| 1. | For all indexes, the orphaned keys will be removed from the index tables: orphaned keys are keys which point to non-existing records. This will be done for all indexes, not just for the indexes provided to IndexCheck on the command-line. |
| 2. | All records, or only the record(s) indicated in the command-line statement, will be looked up in the SQL database one by one, and for each record the following actions will be executed: |
| a. | Of the provided indexes (list_of_tags), the keys to be indexed will be retrieved from the record (let’s call them record keys). |
| b. | For the free-text (word) indexes with keys appearing in the record keys, which have no matching word in the wordlist yet, a new word number will be determined and this word (the missing key) and its number will be added to the wordlist. |
| c. | Of the provided indexes, the existing keys will be retrieved from the index tables (let’s call them index keys). |
| d. | If there are more record keys than index keys, then those extra keys will be added to the index table. IndexCheck will report this action as “MissingIndexValue…”. |
| e. | If there are more index keys than record keys, then the index keys which no longer occur in the records will be removed from the index table. IndexCheck will report this action as “ExtraIndexValue…”. |
| 1. | For safety reasons, create a backup of your application and database, if you haven’t done that yet. It is also wise to try out IndexCheck in a test environment before applying it to a live database. |
| 2. | Copy the IndexCheck files to a temporary folder on the machine that also runs the SQL server. This will spare your local network the extra load. (The Collections \data folder doesn’t need to be on that same server though.) |
| 3. | To run IndexCheck as efficiently as possible, make a few settings for the database. Open the properties of your database in Microsoft SQL Server Management Studio (or a similar tool), set the Autogrowth size on the Files page to 100 MB, and on the Options page, set the Recovery model to Simple. |
| 4. | If you also want to run LinkRefCheck, then always run IndexCheck before LinkRefCheck, not the other way around. |
| 5. | IndexCheck can be controlled by command-line parameters. To provide these parameters, open a command-line window and execute IndexCheck using the following syntax:
<(path to)indexcheck> <path_to_the_data_folder> [fix|check] [list_of_database_tables] [list_of_tags] [priref or priref range] [true|false] [logFile]
The data folder is mandatory and should point to the location where the .inf files are stored. Everything between [] is optional, but if you want to use e.g. the last parameter, you’ll also have to use all the preceding ones. |
| ▪ | If you use the check parameter, then IndexCheck will only report errors and does nothing to fix them, although it will also report keys that would have to be added to, or deleted from, the indexes. On the other hand, if you use fix, IndexCheck will check, add and delete relevant keys and will fix some other errors. The default value is check (or use an asterisk instead).
Use an asterisk to indicate the position of parameters with a default value, if other entered parameters require a non-default setting. See the examples. |
| ▪ | list_of_databases is a comma-separated list (use no spaces in such lists) of database tables to check (names of .inf files without the extension). Not providing this list, or entering an asterisk, will check all database tables. |
| ▪ | list_of_tags is a comma-separated list of field tags of which the index tables must be checked. By default, IndexCheck checks all indexes. Entering an asterisk at this position also checks all indexes. |
| ▪ | priref or priref range is either the record number of a single record to process or a priref range in the format startpriref-endpriref. (The priref range option is available from version 1.10.1.848.) By default (if you leave out a record number or record number range), IndexCheck processes all records in the provided database tables. Entering an asterisk at this position also processes all records. |
| ▪ | true ignores all word (free text) indexes. LinkRefCheck requires correct indexes but doesn’t do anything with word indexes. So when you run IndexCheck for this purpose, ignoring the word indexes improves the performance of IndexCheck. Moreover, Designer has an option to reindex all word indexes. The default value is false. Entering an asterisk at this position also means false. |
| ▪ | If you want reports of errors in indexes to be written to a log file, then provide the name of that text file in logFile. |
| 6. | After running IndexCheck, an overview of the results will be displayed, per database table showing the number of records processed, the total number of deleted keys (in the Extra column), the total number of keys added to indexes (in the Missing column), the number of errors and the run time.
Any errors will be listed individually as well. Of conversion errors (when field data is of the wrong data type and cannot be converted to the proper type), the relevant field tag, its field occurrence, the actual data of the field occurrence that caused the problem and the priref (record number) of the relevant record will be shown: you will have to correct those errors manually, e.g. by editing those records in Axiell Collections. |
Examples:
indexcheck "..\Axiell\data" check "collect,document" * * * "check2.txt"
indexcheck "..\Axiell\data" fix "document" TI * * "check2.txt"
indexcheck "..\Axiell\data" fix * * * * "fix3log.txt"
indexcheck "..\Axiell\data" check
| • | Because of some bug in a specific version of Adlib for Windows, Axiell Collections, import.exe or Axiell Designer, errors may have been introduced into an index. |
| • | If the definition of a field has changed, while the index definition hasn’t, keys may be too long, cut off, or of the wrong data type, etc. |
