Reply To: Database Connections

Forums General Creator community Database Connections Reply To: Database Connections

    Jesse Meijers

    Hi Frenck,

    We spoke about this on the phone where you explained in a bit more detail what you want to build. Basically, you want the data in Triggre to be available to your Business Intelligence system (QlikView).

    In response to your question whether we could allow ODBC connections to our database we can be brief: no. The reason we do not allow this is that we need to guarantee our platform works, which means changes to our data model occur frequently with new updates. This could then potentially break your solution.

    There are a few ways that you could solve this however, which we have looked into for you:

    Option 1 – SOAP
    QlikView has a SOAP interface, which you might be able to call from Triggre. We looked into this for you and sadly they require a special header to be added to the HTTP request to be able to process the request. So while this won’t work for this specific case, it might be possible for other solutions that provide a SOAP interface. Triggre supports most SOAP features, except for complex typing and some other, more exotic, uses of the standard.

    Option 2.1 – MySQL through Zapier
    This would be our preferred way of working in this case. It requires setting up a MySQL database on a server (can be internal) and using the MySQL connector in Zapier. You could then make an automation flow that runs daily and sends the required information to that database. From there, you can pick the data up using ODBC.


    1. Robust solution
    2. Low maintenance costs
    3. Completely no-code solution



    1. Higher running costs than option 2.2


    Option 2.2 – MySQL through SOAP
    The other option is to use SOAP. You would write a small SOAP wrapper around the data you want to store in your MySQL database. From Triggre you can then simply call the SOAP web service. Sadly, there is no general solution for this, so it will require some code writing (though many solutions can generate part of this solution).


    1. Robust; you know when your application changes and therefore you know when you need to update the SOAP wrapper
    2. Very likely lower running costs than option 2.1



    1. Coding required to make SOAP wrapper
    2. Possibly higher maintenance costs due to coding required


    We hope this gives you a good idea of which routes there are to a solution.

    Best regards,


    • This reply was modified 1 year, 2 months ago by Jesse Meijers. Reason: Formatting
    • This reply was modified 1 year, 2 months ago by Jesse Meijers. Reason: Formatting

Get started for free and experience the power of the Triggre platform.

By signing up for your free account, you agree to receive e-mails from Triggre.

By using our site you agree to our use of cookies to deliver a better site experience.