Installing the drivers

When you use a printer, it requires you to install a driver on your computer so that the documents you send to print can be received and printed properly. The same is true with DBMS drivers. You need to install the corresponding driver on the machine you will be sending queries from in order for them to be accurately translated and properly processed by the DBMS, which will, in turn, respond to it by sending the requested set of data.

A very important point you must consider when installing ODBC and OLE DB drivers is the architecture. In most cases, you will find the driver installation packages for both 32-bit and 64-bit operating systems. The 64-bit version is preferred, but, if that is not available, the 32-bit version can also be used with QlikView.

Accessing custom data sources

OLE DB and ODBC are the most common types of connectivity you will find in corporate environments. However, there are certain data sources that cannot be accessed naturally via any of these standards. For these few (but increasing) scenarios, QlikView provides the ability to integrate what are called custom data sources, extract data from them, and manipulate it like any other source.

We can access custom data sources just as we access any other common database: with a connector or a driver. In this case, we can either build our own custom provider or buy it from a third-party seller. The former typically requires using C or C++ code to create the communication architecture between the custom data source and QlikView. Qlik provides a Software Development Kit (SDK) to facilitate the construction of these programs, sometimes even including sample code.

An example of a custom data source would be Salesforce.com. The connectivity for Salesforce is provided by Qlik via a free, add-on, .dll-based adapter and allows rapid extraction of the data stored in this popular CRM system. This .dll-based adapter is what we call a connector, which serves the same purpose as an ODBC/OLE DB driver.

Another common example of a custom data source, which has been increasingly used in QlikView deployments, is the SAP platform. At an additional license fee, Qlik provides a set of .dll-based QlikView connectors you can use to access SAP data (R/3, mySAP, and BW). This connector is SAP-certified and comes with built-in wizards to query the database. It even includes prebuilt QlikView applications, which will certainly help you build the script you need to extract any required table. It's especially useful when you don't know how tables are related or don't actually know the technical names of the fields in a table, which is also very common.

The final example of custom data sources that we want to mention is the Qlik DataMarket Connector (shown as follows). This connector can be downloaded separately from Qlik and gives you access to an online collection of data curated and maintained by Qlik.

Qlik DataMarket mainly contains data on currencies, stocks, demographics, economy, weather, and company information. DataMarket is offered on a subscription basis, but also has a free tier (Essentials Free) with some high-level information.

Accessing web resources via APIs

With the increasing popularity of cloud solutions, more and more data sources are located on the Internet. Typically, these data sources are accessed via an Application Program Interface (API). Examples of sources include social media sites such as Facebook, Instagram, Twitter, and also business applications such as Microsoft Dynamics CRM and SugarCRM.

Qlik offers two add-ons to QlikView that enable you to extract data from (online) resources via an API: the Qlik Web Connectors and the Qlik REST Connector.

Reading table files

The fourth type of data source you will find consists of the most common table files, such as Excel, CSV, TXT, XML, or even HTML. For these types of data sources, one requirement would be that their content is in a readable, understandable structure. It will be easier to extract data from them if they are constructed in the form of a traditional table, that is, only rows and columns (like any table in a database). However, sometimes these files could contain extra information that is not actually part of the core table (such as headers or footers), and therefore, additional transformations via script are required.

The ability to read table files is especially useful when we want to mix information from the DBMS and data generated by the business user that might not be stored in a database. Examples include, budget forecasts, external market indicators, and so on.