Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hi there,
Just interested in how qlikview developers manage the setup we have.
I currently hate the compromises I have to make when deciding whether to have a document available for the IE plugin\Ajax.
IE plugin
Ajax client:
Basically the IE plugin looks\performs better but I need the ajax client for extensions.
This was not a problem until I needed to connect documents together.
If the document with the link uses the IE plugin client and the destination document has an extension (which needs to be the ajax client) I get the following error in the session log files:
Killed because Named User Cal was needed from another client
Therefore I set the default client to be Ajax to avoid this problem.
But I know sooner or later users will be asking for the IE plugin as the default client.
The single client in qlik sense is a major positive in my view.
Does anyone else have this problem?
Thanks
Mark
Mark - IE Performance with AJAX improves in IE v10. Are you there already or have a near term plan to upgrade ? If not, there was a 'Chrome plugin for IE' that can be installed in the users machine. . This makes IE perform faster with javascript and improves performance of QV Ajax in older versions of IE. This will give you better performance of QV with extensions in older IE versions.
Are upgrading IE or installing a client side (non-qv) plugin an option for you ?
Hi Jonathan,
Thanks for the response.
That is very useful to know.
We are currently running IE 9 so I will ask IT support about if we will be upgrading soon.
I will certainly give it a test on a later version of IE and look into the chrome plugin.
Thanks
Mark
Mark,
I don't have a solution, but a similar problem. We are moving slowly to AJAX from the plugin, because of extensions. The default is IE Plugin for us. When the users click on a document that is set for AJAX, it does not open. They have to click view details, then choose full browser version. Do you have the same issue, or have you found a way around that?
Hi Frank - i know this wasn't addressed to me but i can add commentary to this ...
Each user has a default tool that is stored in their profile. A users profile is accessible from access point in the top right corner of the screen. Here they can change their default from IE plugin to full browser version.
Users who have never logged in don't have a profile, but when they do it gets created with a default option. The default option is set in the QlikView MGMT console. Changing this setting unfortunately won't change the option for existing users , just users who have yet to login and have their profile set.
Hi Jonathan,
I am currently using QlikView 11.2 SR8.
When I change the following option in the QMC (System-Setup-QlikView Server-Accesspoint) , it changes which client is used by default:
This also affects the setting in my own profile:
Mark
Jonathan,
The problem is that a user needs to be able to open both plugin documents and AJAX. We have documents that fail (for whatever reason) to work efficiently in AJAX. Explaining to a user that they just can't click on the icon in the Access Point is confusing to them. I was hoping that there was a way for it to know that a document is not plugin enabled and automatically open in AJAX.
Hi Frank,
I know what you mean.
At the moment most users are just happy to get into the documents.
If we go back to having the IE plugin as the default client I will probably look giving users access to the documents some other way but such as links on the intranet maybe.
Not ideal but just a thought at the moment.
Thanks
Mark
I was just reading page 63-64 of the server reference guide and came across these 2 sections .
I haven't tried the setting myself but it may do what you are actually asking for. The star icons that it refers to show in gray on the left side of the 2nd screenshot below.
Thanks Jonathan,
I'll have a look into this on Monday.
The only downside is that it looks like it is a setting the user will have to make.
Thanks for the info.
Mark