Authorizing the Script EXECUTE Statement

Summary: QV Version 12 removes  per qvw control of the script EXECUTE Statement.  In QV12 Server, the default is to disallow all EXECUTE statements.  Any EXECUTE statement will fail unless you turn on the global setting to allow.

The QlikView  script “EXECUTE” statement provides the capability to run external programs from script.  Because EXECUTE may present a potential security risk, it’s use must be authorized. QlikView Version 12 changes how EXECUTE authorization is granted.

In QV11  Desktop,  the script editor Settings pane provides a checkbox labeled “Can Execute External Programs”. This property is set per qvw.

When an EXECUTE statement is encountered,  execution is allowed if the property is checked.  If not checked, a popup is presented asking for permission.

The “User Preference: Security: Always Override Security:  Script” may be checked on to bypass the Execute permission check.

If “Script” is checked, the execute statement will be allowed regardless of the “Can Execute External Programs” setting.

Authorizing Execute works differently in QV11 Server reloads.  In QV11 Server prior to SR11,  Execute statements were always allowed. The “Can Execute External Programs” property has no effect.

QV11 SR11+ Server introduced a new setting


Setting the value to “0” prohibits Execute in any reload on the server, setting  to “1” allows all Execute statements. The default is “1”, allow.

The “AllowExecuteCommand” is set in the QVB settings file “C:\Windows\System32\config\systemprofile\AppData\Roaming\QlikTech\QlikViewBatch\settings.ini”.   See the SR11 or QV12 Release Notes for more information.

To summarize QV11 controls —  In desktop, it is possible to control Execute on a qvw by qvw basis. In Server SR10 and earlier, Execute is always allowed.  In SR11+, Execute may be allowed or disallowed for all qvws via the “AllowExecuteCommand” setting.


On to QV12.  In QV12 IR Desktop, the “Can Execute External Programs” checkbox is present but it has no impact on script execution.   The only way to allow Execute is to check on the “Always Override Security:  Script” User Preference setting. 

I hope the “Can Execute External Programs” checkbox is removed in a future SR as it no longer seems to have any use.

QV12 Server uses the “AllowExecuteCommand” ini setting. The default is “0”, disallow, which is different than QV11.

To summarize QV12 controls — In Desktop, Execute is allowed or disallowed for all qvws via the “Always Override Security:  Script” User Preference setting. In Server, Execute is allowed or disallowed for all qvws via the “”AllowExecuteCommand” setting.

A summary of controls for both versions:



To allow Execute in Qlik Sense, you must enable Legacy mode. Turning on  Legacy mode also allows  file path references in LOAD statements.  I’m guessing most Sense users would not accept this side effect, which may mean that Execute is not practical in the Sense environment.

Execute is not a commonly used script statement. If you are using Execute, I hope this post helps you plan for QV12.




16 thoughts on “Authorizing the Script EXECUTE Statement”

  1. Hi Rob,

    thanks for great post and clarifying this small confusion.

    Do you have any experience with Qlik Sense Database write back? Should we enable Legacy mode as well or this is not needed?


    1. Hi Pavol,
      I haven’t tried SQL update statements in QS. If you get a chance to try it, I would be curious about the results.

      1. Hi,
        I tried it with Qlik Sense desktop 2.2.0 and Microsoft SQL server and it is working well without any settings or legacy mode turn on.


  2. Thx, it works when I open and reload the document.

    But in the QMC it still fails Log: “Error: The source document was not reloaded successfully. DocumentPath=……………”

    I am not sure whether it is related. Any ideas?

  3. Well I have been told that it is a security issue, so despite that I can overrule it on desktop mode, it seems too dangerous on a server to allow, and therefore I guess its not possible.

    1. BTW the release note suggest a chance in the settings file, but then again there is reason that they changed it.

      1. Hi Rob, thanks. Obviously I was aware of that. I should have stated : there seems to be a bug in QS 3.0. Since you have more detailed understanding about this topic and since I see similarities with the QV behaviour : Are you aware of any configuration possibilities to work-around this bug and have QS enabling this?

  4. Hi,
    I need to execute a task if some conditions are verified.
    So I use a .bat file, but I’d prefer to use a direct command like:

    EXECUTE cmd.exe /C start “BD_ETL01_LINK” “Z:\QvSourceDocs\QMSEDX_CommandLine\QMSEDX.exe” -task=”%BD_ETL01_LINK%”;

    It doesn’t work. There is a way for lunch the task named BD_ETL01_LINK?


    1. Could you provide some specifics on what you mean by “doesn’t work”? Error message?

      Is BD_ETL01_LINK the task name as defined in the QMC? Do you have Publisher? Why the % in the execute statement?


    4.1.1 Management of Unsafe Script Execute Commands
    In this release, the AllowExecuteCommand has been set to 0 by default to mitigate against unsafe scripts.
    If you do not consider this to be a security risk you can switch the value back to 1 in the settings.ini file
    located in C:\Windows\System32\config\systemprofile\AppData\Roaming\QlikTech\QlikViewBatch.
    To find where in the tasks the Execute commands fail, set the settings flag EnableQVBLog to 1 in the
    settings.ini file located in:
    When enabled, this setting records violation incidents in the QlikView Batch log located in:
    This setting must be configured in all nodes hosting the QDS service in a QlikView set

  6. Hello,

    I have a problem with my execute statement.
    I’ve checked the “User Preference: Security: Always Override Security: Script” .
    When I execute my qvw document in the desktop, everything work well.

    But if I reload my document with a Tasks in my management console, the reload failed …

    Do you know why please ?


Leave a Reply

Your email address will not be published.