We tried it a while back (using 2.2 or maybe 2.3) but found it pretty tricky to manage well. We haven't looked at it again since Data Manager has been available... perhaps we should?

Have you made any headway?

We have looked at the possibility as well, and are still interested in this matter. Can you keep me posted via this topic?

Thanks in advance!

Regards,

Alexander

Using the Details View with the Tools > 'Show as an editable form' option ticked to facilitate manual input of the data, an Omniscope file (usually with validation formula and other scrubbing alerts defined in data quality-oriented tab views) can indeed act as a Source repository which other Report IOK files draw upon via refresh. This works best when only one person at a time(zone) is doing ALL the inputs into the Source Omniscope file, with the manual data changes being automatically propagated to any number of 'downstream' Reports Omniscope files, and possibly other format Output file formats as well...such as relational database tables.

Although Omniscope files can play many of the roles of relational databases, features like record-locking and sequential commits to support simultaneous inputs/edits to a single field by multiple people, or a mix of people and on-going software processes, require a proper record-locking relational database.

If multiple people and or software processes are all contributing data and making corrections, a input-form and validation screen-oriented relational database like MS Access is best, with the Omniscope Report files using the Access file(s) as their source(s).

Another option is to use a 'hybrid' web-based architecture with a central web-based database like MySQL, using any number of local Omniscope files configured to show the web-based data input forms in Web Views. Omniscope users can submit data and updates/corrections either through the web form or also more structured http: posts of visually-scrubbed Omniscope data via a configured web service, then refresh from the central web database, and use other web services configured in the file to communicate with additonal web server-based processes.

We are interested in using Omniscope as a data entry tool where Omniscope would perform data verification checks, drop down menus etc.

Has this been done before? what is the best way available to do this?

Chris - There are a couple of ways of doing this, 'mostly online', or 'mostly offline', with different cycle times, data quality and workflow accountablity implications. Value-by-value input validation at the exact time of manual input is not necessarily the best way to ensure data quality and accountability. Batch validation with flagged records repeatedly returned for review and correction in exception files can be simpler to implement and may provide a better workflow and end result.

Because Omniscope includes a Web View, which is a standard browser, it will display a standard HTML data entry form page with a button for submitting/posting the data field entries via a web server to to a web-facing database. In this 'mostly online' case, Omniscope validation would take place on the server-side, based on regularly snapshotting and analyzing the latest postings in staging tables, and cycling through a corrections loop before incorporating the uploaded data tables into the production database. In this 'continuous flow' approach, automatically-generated Omniscope exception files containing only flagged suspect entries are repeatedly e-mailed/returned by DropBox etc. to the people submitting the data, with the request that they continuously review and post corrections until the exception file becomes null, with no further exception records left uncorrected...

The other, 'mostly offline' way is to have the process work largely inside a single IOK file per person inputting, with each validated input data set being cleaned before submission, once all Omniscope-flagged records are corrected. Using the Details View Toolbar: {Other} Show as an editable form option, you create a data input form on a tab, and on other tabs you use validation/formulae/alerts and named queries or frozen filters to show any suspect records. This 'mostly-offline' approach depends on the input data sets not actually being submitted until all the flagged/alert records are cleared, but there is no automated server-side review in this 'piece work' approach. Clean input data sets can then be 'batch' uploaded using a web service button, or by forwarding the validated IOK file or Output database table via DropBox (or equivalent) for incorporation in the centralised repository.

This is a popular topic, and there is an Idea thread running to improve this aspect of Omniscope...please contribute/vote here:

http://forums.visokio.com/discussion/1004

Thomas - I am trying to demonstrate to myself the 'mostly offline' concept that you have outlined above. However I am struggling to get the basic setup right.

I have a folder of image files and I want to be able to open each one in turn, identify a Name from the image and type it into a Field called Name. Then have Omniscope validate the Name exists in a predefined list of Names.

Once this concept is working I would like to apply it to multiple Fields with a variety of different data validation tools.

Could someone provide a simple demo tool for this?

Chris - Looks like this is continued on this thread:

http://forums.visokio.com/discussion/2033/sources-deriving-datarenaming-pdf-document-imagess