Qlik Community

QlikView Integrations

Discussion Board for collaboration on QlikView Integration.

QlikWorld 2022, LIVE in Denver CO., May 16-19, 2022. REGISTER NOW TO RECEIVE EARLY BIRD PRICING
Showing results for 
Search instead for 
Did you mean: 
Not applicable

export to native qlikview format from 3rd party solutions


We are a company that build database marketing/campaign automation software. One of our new customers is using QV and we want to build an export to QV.

Why does QV not have a software developer lib which make exporting in native qlikview format possible? There is a lib with wich you first can export to QVE (exchange) format and you need to import this file in QV (an unnecessary complex, not logical and not thread save way). I don't uderstand why this format is made because xlsx works as fast as QVE and much easier with more columntypes as QVE etc.

For Tableau there is a lib which makes it easy to export direct in the native Tableau format and reports are updated automaticly in a fast way

Do i mis something?



5 Replies
Creator III
Creator III

Not applicable

Hi David,

That is what i meant. QVX is a exchange format and not native. it stores the data as utf8 text format as also xlsx does. So the user of qlikview first needs to import this format to native format. I just want to export in native format so the reports are updated.



MVP & Luminary
MVP & Luminary

If you want to speed it up you should take plain text-files and no xml-formats for exports respectively exchanging data. A native API to create qvd-files from third party tools didn't exists but maybe you could use: QVX & QVD Converter Java library.

- Marcus



You can use the QlikView OCX to build a QV app -- a QVW on the fly.  If you use Qlik Sense, there are more friendly API options available to generate an app from code.

Your statement:

" import this file in QV (an unnecessary complex, not logical and not thread save way)"

leads me to believe that you are just trying to compare QV with something you know, and have not taken any time to understand the QV architecture. "unnecessary complex" to you, but robust and effective to those of us who use it regularly.

QV has a visualization layer and a data layer defined by the load script.  The two merged together form an application (qvw file).  The "reload" process executes the script to bring fresh data into the application.

I don't imagine that you want to be responsible for generating the visualization layer every time or managing your customer's modifications to visualizations.

Let's take a look at how QV customers work with external data today. The QVW file lives on the Customer's QV server, and the reload process is executed on schedule set by the customer.

If the data is an extract type, some external process runs on schedule at the data provider to generate a flat file in a known location. The reload process picks up this extract file on schedule, typically via FTP.  Depending on the level of trust and connectivity between the customer and the data provider, the two processes may be coordinated or the data may be pushed.

For some data, such as Salesforce, customers use a connector in the reload script which eliminates the need for any intermediate extract at all, as the data is provided by an interface in Salesforce.  If you don't want to create a connector for your system, there is a generic REST connector that can retrieve data from your system via REST if you can support that.