 |
Home |  |
Using DataLoad | |
Macro Loads | |
Browser Control | |
Forms Playback |  |
Scripting | |
Problems |  |
Each record in your recording must be consistent When recording,
clear blocks & forms that may later contain data DataLoad
validates drop list data Avoid using
LOVs when recording This section documents extra important information and advice that will be useful when using forms playback.
Consistency It is vital that the data you enter in DataLoad produces the same behaviour in the forms as was recorded in your original forms recording session. If the form behaves differently then the load won't work, although the load will normally stop at that point and can be easily shutdown.
R12 Loads In some R12 forms the mouse navigation may not work or the focused field may not change when you click in a new field. This can be fixed by closing the form when it is first automatically opened in recording mode, that is before you enter any data, and re-opening it from the Navigator.
Master-Detail Loads Part 1 Some forms include sections where a variable number of records may be entered and assigned to a header record. For example, a User may have a variable number of Responsibilities in the Define Users form, Suppliers may have zero or more Sites and Customers may have zero or more Bank Accounts. From these examples it can be seen that such Master-Detail sections within forms are common. It is essential that you understand the impact of Detail blocks on DataLoad before recording a load and plan your load strategy accordingly.
Every record loaded during forms playback must require and produce navigation behaviour that is identical to the navigation used during the original recording. Therefore the number of records loaded into detail blocks must be identical for every record in DataLoad. For instance, if you are loading User records every User must have the same number of Responsibilities. For loads where every detail block, that is Responsibilities in the User form or Sites in the Suppliers form, for example, will contain the same number of records this will not cause any problems. Where the number of records to be loaded into a detail block varies you must consider the best way to load this data. You could create a number of loads, each of which can handle a different number of detail records. For instance, if you are loading Suppliers you could have one load that loads suppliers with one site, another for suppliers with two sites, another for suppliers with three sites, and so on. That approach would work but it isn't very flexible. It would also require a lot of data preparation before loading to ensure the correct Supplier records are used with the correct loads.
The best way to handle loads where detail blocks will be loaded with varying numbers of records is to have two loads. The first load will load the master records while the second will load the detail records. For example, to load suppliers and their sites one load would load all suppliers then a second load would assign all the sites to suppliers. Both of these loads would be generic loads that can handle all scenarios, that is it doesn't matter whether the supplier has zero, one or many sites. The site load would load one site per record in DataLoad. That is the load would query back a supplier, add a site to that supplier, save the record then put the supplier form back into query mode ready for the next supplier to be queried back. If a supplier has only one site then it will be queried back only once, but where multiple sites are to be loaded the supplier record will be queried back for each site and the site added to the supplier.
Master-Detail Loads Part 2 The previous section described how to load data that contains varying numbers of detail records. A second factor must be considered when loading any records into a detail block. Supposing you write a load to add sites to suppliers, or for that matter responsibilities to users. When you navigate to the detail block there may be zero or more records already in the block. The number of records in the block will change the navigation required for you to enter a record. For instance, if no records exist then you can probably just enter a new one in the first record, however if records exist you will click somewhere in the block and create a record. The navigation required is therefore different depending on whether or not there is already data into the block, and it may also vary according to how many records are in the block. To ensure your recording works with DataLoad you need to make the navigation consistent regardless of how many records, if any, are already in the block. The best way to do this is to clear the block as soon as you navigate into it. This means the record you enter will then always be the first record in the block. To clear a block select this function from a menu or use a keyboard shortcut, which is 'F7' in R11i/R12.
Finally on the subject of master-detail blocks, it is not always obvious to the user that a block is a detail block. Rather than worrying about whether an area of a form is a detail block or not ask yourself the following question. When you navigate into a block within a form could there already be data in that block? If the answer is ever going to be 'Yes' then clear the block before you enter a record. When you record your load clear the block even if no data is present during your recording. This will ensure the command to clear the block is recorded and it will always be played back, whether there is data in the block or not. Another common load which must use the 'Clear Block' function is loading bank accounts. When you load bank accounts each bank may have zero or more accounts assigned to it. To ensure this load always works you must clear the bank accounts block before the account name is entered.
Drop Lists DataLoad validates the data entered into drop lists because these are restricted to a few valid values. Because DataLoad doesn't initially know what values are valid it needs to learn them. Whenever DataLoad opens a forms playback file it records any new values found in drop lists and this information is later used to validate your data. To ensure DataLoad is aware of the valid drop list options you should record a playback file where you set each of the required drop lists to all of the values you may use. When you open this file in DataLoad it will learn about these values and they will be accepted when you enter them. This file need not follow the normal recording rules, such as ideally recording more than 1 record, however the recording must contain a value entered into a field and this value must be entered before the drop list values are selected.
The droplist data is stored in a file called droplists.dat in the same directory as dataload.exe. The value that is entered in the drop list field must be the same as the internal value used in the form. This is usually the same as the value seen by the user but this isn't always the case. If, after teaching DataLoad what the valid values are, DataLoad rejects the data you enter, you should check the droplists.dat file to try and determine what the valid value is. This file can be opened in any text editor, such as Notepad.
List of Values For reasons of performance and reliability data should be directly entered into fields, and lists of values, or pick lists, should not be used. However, if a LOV must be used then DataLoad fully supports this functionality and will produce an appropriate playback file. Some pick lists contain multiple columns and although only the first of these represents the value displayed in the Oracle field, all of these values are required in the playback file. Where a LOV entry requires multiple values DataLoad will enclose each value in the spreadsheet cell with double quotes, and values entered into the spreadsheet must also be enclosed in double quotes. The only case where this doesn't apply is where only a single value is required by the LOV, in which case no quotes are required. Finally, when DataLoad saves the playback file it validates that each LOV cell contains the correct number of values. If values are missing then DataLoad will insert blank strings to replace these values, however it is unlikely that the load will work with these values. Where DataLoad does need to insert missing values a warning message will be displayed.
Multi Line Data In DataLoad V4, if your cells contain data with multiple lines, e.g. HRMS formulae, each new line must be represented in the DataLoad cell by '\n'. When you edit your data each newline you require must also represented by '\n' (without quotes). The \n is not required in DataLoad V5 and multiple lines can be entered in DataLoad V5 cells in the normal way.