In my QVD Dictionary app, I parse the DB table names out of the SQL statements. That works for a simple select but yields less useful and sometimes incorrect results for more complex SQL.
The current notion of a database “source” is whatever appears after the FROM keyword in the SELECT. There are some improvements I’d like to see. For example, we can see that something labeled “Proceeds” is associated with twelve different definitions Those variations may indicate a business difference or perhaps just different set modifiers - you have to look to see - but it can point to something worth reviewing.įor complete lineage results, you must run the scanner on the same machine where the reloads took place, using the same path mapping. I like the idea of counting expression variations against a label. The dashboard presents some interesting displays. The scanner reports on some attributes that were previously difficult to scan, such as the document “Generate Logfile” property. You can use the dashboard objects as delivered or binary load the model to create your own analysis. The data model produced by QGD is pretty comprehensive, and in my limited review, accurate and useful.
The scanner tolerates older (pre V10) qvws without error. Not a problem as this is now supported by QT. The dataflow cannot be modified by the customer. QGD uses a Connector, an Expressor dataflow, and a hidden script to do the scanning. QGD is a QT supported product, whereas MetaScanner was provided as a sample app.
QGD replaces the MetaScanner sample that was available on the Community. QGD is a Qlikview app that scans files from your Qlikview deployment - QVW, QVD, log files - and builds a dashboard of metrics that can be utilized to understand and manage your deployment. It’s marked as “beta” but it looks to be pretty close to complete. The Qlikview Governance Dashboard (“QGD”) is now available for download in QlikMarket. If you are reporting a possible bug, please include the contents of the Logtext on the Main sheet in your report. If you have problems or questions on DocAnalyzer, please follow the reporting instructions on the About sheet. While not really the mission of DocAnalyzer, I had the framework there I so added the Font sheet. – A customer requested the ability to analyze consistent font usage in his application. Clicking the “Goto Object” button will take you to that object in the target document. – On the Object sheet, select to a single objectId. – The Groups sheet show the composition of Groups and their use. In addition to identifying unused Fields, DocAnalyzer has picked up a couple of useful features for understanding target documents. A simple way to remove it from the model is to add a You may want to remove them for neatness but the impact on performance will be insignificant.Ī field may be required as part of the script processing or it may have been loaded by a “LOAD *”. It makes sense to consider removing the “OrderTime” field. The main sheet provides an input field for specifying the document (target document) to be analyzed: I say “probably”, because DocAnalyzer is a guide you must apply your own common sense and knowledge of the application before following it’s recommendations.ĭocAnalyzer uses a macro that requires system access. These are fields that can probably be safely removed without affecting the user experience. That is, Fields that are not used in expressions, dimensions or keys. I thought it was worth revisiting.ĭocumentAnalyzer is a QVW that analyzes another QVW and identifies Fields that are unused by the UI. It’s since undergone a number of improvements and there is a whole new audience of QV Developers out there. I first blogged about DocAnalyzer in 2009.
A tool that can assist with this process is DocumentAnalyzer, freely available from my downloads page at An first step to improving the performance of a QV Document is to remove unused fields from the data model.
0 kommentar(er)
