Testing your application for errors
Contents
Axiell Designer has a special tool with which you can check your application for certain common errors. Start this Application tester tool by choosing Tools > Application tester or by clicking the button for it in the main Axiell Designer window:
This was originally a tool used by the Adlib developers to test their own work on Axiell Designer, by checking the files for compatibility and consistence. This was to make sure that Designer can read files from all versions of Adlib properly, and save them to disk (unmodified) the same way the old ADSETUP or DBSETUP tools would. These specialized tests can be found on the Advanced* tab, and most users can disregard them.
However, on the Options and file types tab you'll find settings to perform a consistency test on your own application. This test checks the file types and work folders that you select on this tab, for:
| • | errors in path names (meaning references to Adlib objects, like screens and linked files), that point to missing files or typing errors in the path names; |
| • | errors in link definitions (meaning the syntax of path names: if file separator characters are being used properly, although in Designer you no longer see these characters in object properties because paths to datasets are now split up in different properties); |
| • | multiple (duplicate) use of tags, link reference tags and index names (the latter from 7.6) in .inf files (because these must be unique). If duplicate case-insensitive index names exist, then just rename one of those indexes and reindex both indexes to solve the problem; |
| • | undefined tags which are being used in linked field definitions, like undefined link reference tags. Every tag you use, should be defined in the data dictionary. |
| • | spaces in field names. |
| • | screen field tags which have not been defined in the data dictionary (available from 7.4): for all data fields (not system fields) on screens used in all data sources in an Adlib application, the Application tester checks if the tag associated with the screen field has been defined in the data dictionary of the database associated with the data source. In the past these undefined field tags have never been a problem, but in Axiell Collections a more strict validation of data structures has been implemented so that all tags used on screens need to have been fully defined in the data dictionary, providing the correct data type and such. So next time you use the Application tester on your applications, test results like the following might show up too, indicating that your application is not quite ready to be exposed via Axiell Collections: So if you plan on deploying Axiell Collections or if you simply like your databases' data dictionaries to be in perfect order, you should take action on these test results. The solution is to create an actual field definition for all such reported fields in the relevant databases. From the label for the screen field, the screen(s) it is located on and the database the field should be specified in, you can usually easily deduce the basic properties for the new field definitions. However, if you think the Data type of a field should be anything other than Text, you have to be sure that all data that was entered into this field previously is indeed of the other type! Undefined tags on screens may contain any value because they are implicitly considered text fields, but once you specify the field in a database as an integer, numeric or date field, etc., then all existing data in that field should be of that type as well, otherwise you may inadvertently create data corruption. So if you are not sure about the type of your existing data in these fields, just assign them the data type Text, set the Maximum length to 0 (or otherwise sufficiently large) and let them be Repeatable. After you've defined all these fields in their respective databases, you're already done! There's no need for any data conversion or reindexing. |
With regards to Adlib SQL databases the Application tester (from version 7.4) also checks the following:
| • | Can a connection indeed be made to the SQL database? If not, please check the Data source name, Server, and User name and password settings in your Adlib database properties in relation to the settings made in SQL Server. |
| • | Does a data table for each Adib database (e.g. collect, thesau, etc.) exist? Data tables might still be missing for copied database definitions (.inf files), since those won't be created automatically when you copy a database definition. A SQL data table and some associated required tables can easily be created by right-clicking the new database definition and selecting Clear database in the pop-up menu. It won't create index tables, but you can easily create those after "clearing" the new database by reindexing all indexes for this new Adlib database. Be sure to apply the Clear database option only to the new database definition, not to your other Adlib database definitions as it will empty the relevant SQL tables! It would be wise to create a backup of your SQL database before using this option. |
| • | Do all index tables (e.g. collect_invo, thesau_term, etc.) exist? If SQL tables for certain indexes created in an Adlib database definition (.inf) are still missing, you can easily create the relevant tables by reindexing those indexes from within Designer's Application browser. |
Other checks added in 7.4:
| • | Do all source and destination fields listed in the Copy fields from linked record box on the Linked field mapping tab have a field definition in the data dictionary? |
| • | Do all source and destination fields listed in the Write fields to linked record box on the Linked field mapping tab have a field definition in the data dictionary? |
So, first select a work folder and mark the desired options, and then click the Start button to start the test. Click the Stop button if testing takes too long, and you want to cancel the process.
Feel free to try this tool, but do realize that you can't use it to test every aspect of your application on validity because the test is limited. This means you can't rely on this tool to tell you if your application and databases are built correctly if it reports no errors, but you can find certain errors.
Any errors that you do find using the Advanced tab of this tool, may be of interest to the Adlib developers, to improve Designer; in other cases you may be able to use an error report to improve your own Adlib application.
Progress and error report
The lower half of the Application tester displays progress information. If the tested files contain errors, you will be notified and a report is generated in the main Designer window. You may add remarks by typing them anywhere you wish. It's also possible to save this report as an .rtf file, that you can open in most text editors. If the report is long, you can search it for any term with Ctrl+F.
Non-modality of the application tester
The application tester stays active (and running if applicable) when you close it, which means that any errors are still being written to the main Designer window, and that if you open the tool again you'll see the results of the current/last search.
* Test the writing of files through options on the Advanced tab
Mark the Write test option to have the Application tester create temporary copies of the files in the current work folder, save them to disk and check them for consistency; only .fmt files (screens) are excluded from this test. So the test is non-destructive, it doesn't change your existing files. The temporary copies are automatically removed after the test.
In case a write test fails, the developers of Axiell Designer may need the temporary copy of that file to analyse the problem. Mark the Keep failing write test files option to save those copies. They have the same name as the original file but with the extension .object_test.