Visokio website     Downloads     Video tutorials     KnowledgeBase  
DataManager: More attributes in IOK "File metadata" block (2.8+) - Visokio Forums
DataManager: More attributes in IOK "File metadata" block (2.8+)
  •     steve April 11, 2012 3:17PM
    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).
  • 5 Comments
  •     steve May 3, 2012 2:44AM
    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".
  •     steve May 3, 2012 5:06AM
    Updated today to include further information. I've updated the top post accordingly.
  • admin May 10, 2013 11:53AM
    This feature is now publicly available in 2.8 beta:
    http://forums.visokio.com/discussion/2130/omniscope-2.8-beta
  •     acohen September 11, 2015 12:36PM
    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.

Welcome!

It looks like you're new here. If you want to get involved, click one of these buttons!

Sign In Apply for Membership