New in 2.8, the "File metadata" data source (available in DataManager and from "File > Open folder of files/media") now includes basic metadata from within IOK files:
- Record count - Field count - Field names, comma-separated - Source file/URL/summaries, comma-separated - Tab names, comma-separated (includes hidden tabs).
Note: this feature allows you to point Omniscope at a folder of files and get a table of metadata, one record per IOK file.
This is like a metadata equivalent to "Batch append files".
A related idea would be to point Omniscope at a single file and get a table of metadata for that single file. Since it wouldn't be listing more than one IOK file, it could afford a different and richer data structure, such as: - a record per IOK tab, with metadata fields about those IOK tabs - a record per IOK field, with metadata fields about those IOK fields - a record per upstream source in the IOK
This would be like a metadata equivalent to "File source".
We think that the file metadata is a great idea and if it is able to be expanded slightly it could greatly help us in stabilising certain aspects of our reporting environment.
Basically we love that we can automatically get the "Sources" of an Omniscope report using the "File Metadata" block. We would like to extend this to be able to give us another column called "Tables/Views" which would further provide the list of tables/views that are being queried from each source. And if possible another column actually detailing the fields being queried from each source.
The value add here is that we will be able to easily and automatically maintain a list of our Omniscope report dependencies and share this with the relevant Database owners down to field level. This way when they are considering making a change to a specific table/field in their database they and we can immediately see which reports may be impacted.
The results would be fewer failures due to a database change implementation that was not fully tested downstream. A real issue for any business critical operational reports.
Currently we would have to track these dependencies manually which will take some time and also increases the Ops risk.