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 ?!
Can anyone shed some light on this?
Thanks a lot!
As far as I know one user has the Username and Description.
The wrong field according to you might be the description of that user.
Check the spelling of that username in the various fields of Active Directory. I know that the QlikView services often look up FullNames from usernames in AD.
well, that is (part of) the issue:
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.
I'm probably looking in the wrong place...
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.
Thanks a lot!