I have a very strange phenomenon: I have modified the .ini file of our QlikViewServer so that it generates an xml file with the Cal_allocation_data, along with the .pgo file. I have furthermore downloaded an app from the Community and slightly adapted it to reflect the data that we have. That way we have an easy way of tracking CAL_allocation.
Now, there is a phenomenon with one name:
- The surname is > Biskiewicz < - the correct writing is with > cz <
- Both our personnel database and MS Outlook know that name only once, with the correct > cz <.
- In the .xml file, the field > Username_full < knows the name only once - but with a > c < which is plainly wrong.
<=> Even stranger, the field > Username_short < in the same file knows both variations of the name (the incorrect one with a > c < and the correct one with a > cz <)
=> A simple COUNT shows that there are actually two identical names in the list of the field > Username_full < => so it might be that that field has a character_limit.
<=> What is even stranger, though, is that, according to this app, licences are associated with that person written with a > c < <=> I cannot link that to the personnel info from our database because that in turn knows only one variation of the name, the one with a > cz <. <=> Even the QEMC, when I select a specific QlikView_app, knows the name with a > cz <
=> Obviously, the QlikViewServer, for writing that xml file, draws the names from somewhere else than the QEMC ?!
AfaIk, the AD is where Outlook gets the names from - and Outlook knows only one variation of that particular name - which is the correct one with a > cz <.
Moreover - and that is actually the strangest part of it - the QEMC shows me a name associated with several Document_CALs, and that is also the correct one with the > cz <.
So how come the app based on that xml file shows me those licenses associated with the name with > c < ?
(and that is irrespective of whether I choose to display the full or short name in the chart, the name with > cz < does not have any licenses, acc. to that; And I have already deleted the xml once to make sure there can be no old leftovers.)
well I'm stuck at the moment. I had a look in one of the CallData.pgo.xml files I currently have at hand, and the only field I found is a <Name> field that contains domainname\username. No missing last characters there.
nope, you are looking in the right place - the code of the app I have downloaded uses that NAME field twice, once with the domain as > Username_full < and once without the domain as > Username_short <.
The strange thing is thus twofold:
- Where does the service pull that second (wrong) variation of the name (the one with a c) when neither our HR_database nor the AD (as far as I can judge) have that?
- Why does that same service associate the two assigned licenses with that wrong variation when the QEMC shows me the correct one associated with the licenses?
Just to make sure: try my experiment. Create a new document and in the load script, load CallData.pgo.xml as XML. Reload. You'll get a loop - ignore that. Now put the Name field as a list box onscreen. Do you still have different spellings for that particular <Name>?
sorry for the delay. I just come back from my holidays.
I tried your experiment now and when I put that name_field onscreen - I wonder how that app I have downloaded makes two fields out of that, I'll have a look
=> There is only one variation of that name, but it's the wrong one - with just a 'c' at the end ('cz' would be correct)
Never mind that particular name, the person belonging to it does not work here anymore, that .xml is not up-to-date - I don't have access to the real one, I am sent one when I ask for it - that does not solve the issue, but I guess it does make it harder to track.
There currently remains one other example for this issue - a person called > Jürgen < but that is different again, oh my - with that, our personnel database and our AD definitely do have different data - it is written with > ü < in the one, with > ue < in the other.
The QMC shows me the license is associated with the one with a > ue <, as it is in the AD <=> since that is not consistent with the data in our personnel_database, I cannot associate this with the information of the plant and team where this person works.
Can I somehow use a mapping_table or otherwise edit the associations in QlikView so that > ue < and > ü < are treated the same and the link works anyway? I suppose that will occur more often whereas names with a > cz < at the end are supposedly not so common here.