Problem with inputfields on qlikview 10

[tduarte]

We had an document on v8.5 that was having performace issues so we decided to have a go with QV10.

After reloading the document in QV10 I realized not everything was working,  mainly the inputfields.

I found someone suggesting here that we should always had an unique ID to avoid issues with inputfields. So I used Rowno() in the table that contain the inputfield and it all looked fine. But it wasn't!

We load the inputfields with a default value of '0'. After a reload that value is keept but even if you save the document, close and then when you reopen it , the inputfield will have values from 0, 1, 2, 3, ... onwards...

It sets values to the inputfield just by closing an reopening the document.

Has anyone experienced this? Any ideas of what needs to be done to fix it?

[ToniKautto]

My initial guess is that your issue is related to the data set containing NULL values or data model contains synthetic keys, meaning that your chart object shows rows that do not really exist in your data. Your description sounds a bit strange though, so please attach a sample QVW to make evaluation of this a bit easier.

In case the app contains sensitive data, please use sfcrambling fucntion to make fields unreadable;

Settings > Document Settings > Scrambling

Also feel free to remove objects (company logos) that are not relevant to this problem, to make the app even more anonymous.

[tduarte]

Toni, I don't have any NULL values on any of the key fields of the table in question or any synthetic keys in the data model.

Basically I have 3 tables, each with a inputfield.

This is what I'm doing on the script:

Inputfield input_price1;

Table1:

Load

...

'0' as input_price1,

...

I then have a 3 pivot tables with an expression that will take the corresponding inputfield value if different from '0'.

The problem I'm having is only with one of the tables/inputfields.

I created a list box with the field input_price1 and after reload all values are '0' which is correct. So I save the document, close it and then when I open it again, the values change to 0,1,2,3,4....etc.. up to a bit more than the number of records.

How is that even possible?

[ToniKautto]

Please attach a sample QVW, to make it easier to evaluate.

[tduarte]

I manage to find a temporary solution by storing into qvd the table that contains the inputfield with the issue, then dropping the table and then loading the table again from qvd later in the script.

It must be a problem with the links between the table or the pointers.

I have forwarded this to Support and will update later.

[tduarte]

Reply from Support:

     Thank you for bringing this problem to our attention. We have logged it

     with our Issue Analysis team - ID 39541. If approved as a bug, the

     issue will hopefully be fixed in the next Service Release.

     I will advise you if there are any further developments in this regard.

     Please accept our apologies for any inconvenience.

All I can do now is wait.

[tduarte]

Hi all,

The paragraph below was taken from the QV10 SR3 release notes:

"Inputfields are not compatible with joins or resident loads.

The reason for this is that an inputfield must be read one time and one time only. Once

the inputfield is read it is added to an inputfield table and this table cannot be

tampered with. Joins affect the table and for that reason inputfields are disabled when

combined with joins. Resident works slightly different but it also affects the inputfield

table and it is disabled for the same reason."

I tried adding the input field only AFTER all joins or resident loads that use the table but that didn't work.

Input field was converted to a normal field so I don't get it.

[Anonymous]

I've got the same exact problem. Please update this topic if you manage to find a solution.

[hdonald]

Hi,

Another method might be to create an in-memory table with just a key field and the input fields using a 'from' load, then rely on the associated join to use the input fields as before.

It means creating an extra table but it would at least put an explicit table in your data model that shows what is going on with the input fields.

This seems to work in my test environment - I'd be interested to know if anyone else is using the inputfields in this way,

Regards,

HD

[Anonymous]

My problem turned out to be null values. However, this is not a problem in Developer. It's only when reloading via Publisher that these nulls cause a reload failure.