Differences in Input Fields in various versions
Article Number: 000003085 | Last Modified: 2018/06/12
The way input fields are managed has changed between v9 and v10. In v9 (and earlier), input fields were
linked to the orignal data by load order only. The input field values were always associated to the same
record number, which caused problems if the load order changed, for example by inserting new values. This
means that it was possible to have duplicate rows in a tablein v9 and still have input fields associate
with the correct rows.
In v10, input fields are linked by a "key" and load order. The "key" is made of up all the fields in the
table. Input field values are linked to the same record as long as the values of the other fields do not
change AND the load order does not change. This means it is NOT possible to have duplicate rows in v10
when using input fields. QlikView v10 will show an error, "Duplicate keys when loading Input Fields" when
(re)loading a document created prior to v10 if the rows utilsing input fields are not unique.
When upgrading a QlikView document to v10 the QlikView developer should ensure that there are no duplicate
rows in tables utilising input fields. In most situations, the QlikView developer will already have a
mechanism in place to ensure unique rows. If not, the developer should utilise the technique in this
document to create unique rows.
Create unique rows.
Move the input fields to a separate table that contains just a unique key and the input field. This MUST
be done in v9.
1. Remove the input field from the original table and place a row number into the original table.
2. Create a new table with a row number and the input field only.
3. Reload the document in v9. Verify the input fields are correct.
4. Open the document in v10, verify the input fields are correct
5. Reload the document in v10 and verify the input fields are correct.
After the above was written additional information was uncovered, adding for completness:
Two additional file attachments provided - 32383_JTN_test v3.zip (Tests 1-4) ; 32383_JTN_test v4.qvw (Test 5)
Reload the data in 32383_JTN_test v3.qvw in both v9 and v10. The file works as it always did in v9 but produces the duplicate keys error in v10. This is our baseline test. I also received the duplicate keys error in the original file when I try to reload the data.
Using the 32383_JTN_test v3.qvw file, open the script editor and uncomment the EXIT SCRIPT at line 133 of the ‘Values Normal’ tab. Reload the file in both v9 and v10. You will receive a synthetic key but the file will reload correctly in both versions. We have now confirmed that the CONCATENATE in the first test (and original .QVW) produced duplicate keys and is one of the issues.
Using the 32383_JTN_test v3.qvw file, open the script editor and move the ‘Values Normal’ tab ahead of the ‘Saving’ tab. DO NOT comment out the EXIT SCRIPT at line 133 of the ‘Values Normal’ tab. Reload the file in v9 and v10. The reload will fail (at the very end of processing) in v10 but complete without errors in v9. Interesting….
Using the 32383_JTN_test v3.qvw file, open the script editor and comment out the INPUTFIELD statement on line 15 of the ‘Main’ tab. Reload the script in either v9 or v10. The reload will succeed in both versions. However, now open the table editor and look at the Information Density of the two fields that we want to be input fields. The fields are LogCost.Total.Actual.Simulation, Turnover.Turnover.Actual.Simulation. Both of these fields have a density of 16% meaning a majority of the field values are null. I believe the issue in v10 input fields is with null values in an input field. This also means that part of the problem is the data the developer is working with.
Reload the attached file. This only loads the Valuesnormal.qvd file; however, there is a test for null values on the two input fields. When a null values exists it is replaced with the word ‘NULL’. This produces 100% information density and the file reloads in v10. If the user is concerned about persisting input values from v9 to v10, I would recommend performing this load in v9 one time for the existing data and then continue with v10 going forward.
To see the technique in action, reload the attached document in v9 and change a few values in column F3. Then
open this document in v10. The input field values are still correct. However, if you try to reload the
data in v10, you will receive the "Duplicate keys when loading Input Fields" error and the entire script
will fail. Next, re-open this document in v9. Comment out the script on the "v9 Load" tab and uncomment
the script in the "v10 Load" tab. Reload the data in v9. You will see that the input fields are still
correct. Save the document and open it in v10. When you reload now there will be no error and the
input field values are still correct.