Qlik Community

QlikView Management

Discussion Board for collaboration on QlikView Management.

datanibbler
Esteemed Contributor

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

Tags (1)
8 Replies

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

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

datanibbler
Esteemed Contributor

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


Hi Kaushik,

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

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

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
Esteemed Contributor

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

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

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

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
Esteemed Contributor

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

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?

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

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
Esteemed Contributor

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

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

Community Browser