Skip to main content
Announcements
NEW: Seamless Public Data Sharing with Qlik's New Anonymous Access Capability: TELL ME MORE!
cancel
Showing results for 
Search instead for 
Did you mean: 
datanibbler
Champion
Champion

Names in CalData.pgo.xml not same as in QÈMC?

Hi,

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!

Best regards,

DataNibbler

8 Replies
kaushiknsolanki
Partner Ambassador/MVP
Partner Ambassador/MVP

Hi,

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 once.

Regards,

Kaushik Solanki

Please remember to hit the 'Like' button and for helpful answers and resolutions, click on the 'Accept As Solution' button. Cheers!
datanibbler
Champion
Champion
Author


Hi Kaushik,

in that CalData.pgo.xml I cannot find a field with the description of a user - there is only one field >Name<.

Peter_Cammaert
Partner - Champion III
Partner - Champion III

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.

Peter

datanibbler
Champion
Champion
Author

Hi Peter,

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.)

Peter_Cammaert
Partner - Champion III
Partner - Champion III

Hi DataNibbler,

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...

datanibbler
Champion
Champion
Author

Hi Peter,

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?

Peter_Cammaert
Partner - Champion III
Partner - Champion III

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>?

datanibbler
Champion
Champion
Author

Hi Peter,

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!

Best regards,

DataNibbler