4 Replies Latest reply: Dec 2, 2010 6:06 AM by Gordon Savage RSS

    QV 10 - What happened to plugin_alldocs.htm?

      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?

      Thanks,

      Michael

        • QV 10 - What happened to plugin_alldocs.htm?
          Gordon Savage

          I had exactly the same issue migrating from 8.5 to 9sr4 and this is the response I got from support:

          Dear customer,

          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 just re-used the asps from the old install.

          Regards,

          Gordon

           

           

           

            • QV 10 - What happened to plugin_alldocs.htm?

              Gordon,

              Does IIS have to be installed to use those asps? Trying to do this without IIS if possible.

              Thanks,

              Michael

                • QV 10 - What happened to plugin_alldocs.htm?

                  Assuming I can use the asps without IIS, how do I figure out which files to copy?

                  Thanks,

                  Michael

                    • QV 10 - What happened to plugin_alldocs.htm?
                      Gordon Savage

                      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.

                      Regards,

                      Gordon