A binary load must be the very first statement on the first tab of your script and you can only perform one binary load per script; that's all there is to know about them. The syntax couldn't be simpler either:
There are basically two main uses for binary loads. The most common is to share a data model between 2 QVWs. This can be as simple as copying the model from an existing QVW when adding a new reporting app to an existing solution. Whilst his is a perfectly valid technique, it assumes you want the exact same data model in both files. But this doesn't have to be the case, there is nothing to stop you dropping tables from the model or loading additional tables once you've performed a binary load. The benefits of this are straight forward, it saves development time and speeds up the reload process by avoiding having to load a complete new model from data source or QVD.
|Fig.1: Basic use of binary load|
- Start with a standard incremental build process using a QVD to store the transaction table and a reporting interface which loads in the QVD.
- A new QVW is created which runs each night or even weekend. This loads in the contents of the QVD and adds it to any history it already has. Once complete it empties the QVD. The incremental process creating the QVD will therefore mean the QVD stores only records added since the last reload of this new QVW.
- The reporting interface is modified to first binary load the new QVW to get the history data before then concatenating the QVD.
|Fig.2: Binary as part of an incremental build|