In version 8.5, we had a url redirect setup to go from <servername> to <servername>/qlikview/plugin/plugin_alldocs.htm. This is convenient because it lists all the qvws in all the folders each user is authorized to see.
In version 10, however, it appears that this html file no longer exists. Is there a similar page in QV 10 to which I can redirect?
I had exactly the same issue migrating from 8.5 to 9sr4 and this is the response I got from support:
Unfortunately due our focus of improving our product we do not support any longer the task you wish to have. In case you do not see any other solutions please contact your account manager for a consultant.
Our apologies for any inconveniences.
Original Case Description: I have rejected using AccessPoint and would prefer to use the legacy asp pages (specifically the plugin_alldocs.asp) but there does not seem to be any information as to what files need to be moved nor where to.
Are there any instructions?; there are many differences to what I see in v8.20 eg no plugin_settings.asp
I dont know if it only works with IIS (which is what we use) but I suspect it does. The files I copied to the folder identified for 'Qlikview Plugin' in the IIS settings were:
Copy From C:\Program Files\QlikView820\Server\QvClients\QvPlugin To: C:\Program Files\QlikView \Server\QvClients\QvPlugin Install.inc Plugin.asp Plugin_functions.asp Plugin_settings.asp
Copy from C:\Program Files\QlikView820\Examples\QvWebpages\plugin To: C:\Program Files\QlikView \Server\QvClients\QvPlugin Plugin_alldocs.asp Folder.gif Openinnew.gif
Copy FOLDER C:\Program Files\QlikView820\Examples\QvWebpages\images To: C:\Program Files\QlikView \Server\QvClients
Incidentally, this is why we use IIS instead:
We are currently at v8.20. IEPlugin only displays as an option on the AccessPoint when the plugin is v9 - we would therefore need to have the plugins at v9 at the same time the server is upgraded if we are to use AccessPoint. Ajax is an alternative method which is now much more mature and could soon be viable.
Document reloading is achieved via remote command/batch file initiated by our business system (e.g. post invoicing run) - not through a schedule on the Qlikview server or QMC schedule. When using backup, the version created by the reload will be visible on the AccessPoint. There is no option to direct the versions to a specific location, they are simply created in the same place as the document. These versions would therefore need to be moved to another place necessitating changes to each reload process.
Via an asp menu, we invoke documents using qvp protocol to enable a call of initial macro or parameter passing. AccessPoint does not seem to offer the ability to do either of these things. The initial macro call is mainly historical as the documentation has always insisted that the document OnOpen event has no meaning in the server environment (see P338 of v9 QV Reference Book II). If the OnOpen event can be used (which would indicate the documentation is wrong) each document would need to be changed to add this trigger event. Parameter passing would still need to be resolved.
The AccessPoint interface is rather clumsy and does not conform to standards; asp offers better freedom with the user interface.
Our people understand IIS!
A major feature of AccessPoint is its ability to load balance across servers, but we are a single server environment anyway.