Windows Installs

Windows Installation

This section documents the Windows installation process for Visokio applications, and discusses options for deploying our applications in various organisational and network/desktop administration contexts.

Note: Visokio applications are Java applications which will run on most operating systems, including Linux and Mac. However, only the free Viewer is currently available for non-Windows operating systems. The activation process to upgrade free Viewers to Standard, Professional and Enterprise Editions is not yet supported on non-Windows operating systems. Details on installing on non-Windows operating systems are available here.

Typical Install Sequences (Windows)

The typical Windows stand-alone installation sequence for each of our products is included in the User Guides:

Omniscope Windows typical install

FeatureFinder Web Windows typical install

Administered Installations (Windows)

The sections below cover network installs and options for centralised deployment, including any known issues and workarounds:

Administered Desktops Covers roll-out installation options, including options for centralised deployment

Install Configuration Files

Class Load Logs

Test Scripts

  Z:/path/to/OmniscopeInstaller.exe /S

# This is the installation configuration file.
# This is used to configure initial startup of the application.
#
# All properties are optional, and if defined, each line must not contain redundant whitespace
# To enable/disable a property, remove/add the # sign (# means comment)

# This is an optional manually-specified Java VM installation folder.
# It should contain bin\javaw.exe, and should be Java version 5+
# JVM_DIR=C:\Program Files (x86)\Java\jdk1.5.0_14

# This is an optional manually-specified max memory cap for the Java VM, an integer specifying the
# megabytes to allow the JVM.  Must be at least 64.
# If unspecified, 75% of physical RAM will be used as the cap.
# MAX_MEMORY_MB=300

# Optional property specifying additional space-separated JVM options.  Default is blank.
# Example which enables "heap dump on out of memory", which generates files such as 
# "java_pid4972.hprof" in the program folder, for submitting to Visokio for analysis
# (requires Java 1.5.0_07+ or Java 6):
# ADDITIONAL_JVM_ARGS=-XX:+HeapDumpOnOutOfMemoryError

# Optional property which if true causes output to be redirected to
# "Visokio_output_log.txt" in My Documents
# LOG_TO_MY_DOCUMENTS=true

# Optional property which, if true, disables the default heap tuning parameters
# which at time of writing are -Xms64M -XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=30
# DISABLE_DEFAULT_HEAP_OPTIONS=true

Rebranding Omniscope

Rebranding Omniscope

Corporations deploying Omniscope centrally have the option of rebranding Omniscope 2.3 or later to add corporate identity:

 

 

Instructions

To rebrand Omniscope deployments, include a "branding" folder within the deployed application folder (typically such as "C:\Program Files\Visokio Omniscope\branding"). Into this folder put various files. All files are optional and their presence takes precedence over the default application behaviour.

To get started, download the sample branding folder containing the optional files. Add your branding to the images as necessary. Some images are size sensitive, some are less so. Edit the config.properties file appropriately - this is documented inside the file itself.

To add custom colour themes, create the themes in an open Omniscope file using the Appearance menu and save using the Themes menu item. This will create an XML file either in the program folder or in your user profile. Move this into the Themes subfolder of the branding folder.

Edit the "config.properties" file to customise other settings such as colours and fonts - these are documented inside the file itself. Please note that further customisations are available than specified in this file - contact us for more information.

To preview your results, install Omniscope normally and put the work-in-progress branding folder inside your Omniscope program folder, then start Omniscope. 

Note: on Vista, you will need to work on the branding folder in an editable location such as My Documents, then drag with Vista UAC confirmation into the program folder when you want to see the results.  On XP, you can edit directly in the program folder.

Download

Download sample branding folder (ZIP) - requires Omniscope 2.3 or later.

Java Issues

Java Issues

Java is freely down-loadable, open source software that provides a 'virtual machine' or VM that permits software to run on many different machines and operating systems. For more information on Java, see Wikipedia

Visokio applications are pure Java applications that run 'on top' of a Java virtual machine which runs 'on top' of your machine's operating system. This means that you either must have Java 5 or later installed before you can install Visokio applications, or you must use the Full installer which includes Java 6, also available here.

Java is open-source software that is being continuously improved. Periodically, there is a new release of Java, and known issues in Java emerge which are relevant to installation and performance of Visokio applications.

Java compatibility

If your systems already have a conflicting version of Java installed (such as the Microsoft VM, or Java 1.3.x) you must use the full installer. This creates a private Java VM (PVM) specifically for Visokio applications which will not affect any other part of your system.

The private Java VM, installed in Program Files/Visokio Common/pvm15, must be deployed as well as the main Visokio program folder, for example the Omniscope folder: Program Files/Visokio Omniscope.

Alternatively, it is possible to specify your own Java VM, by creating/editing the installconfig.properties file within the main installation folder. See Centralised Deployment for more information.

Known Java Installation issues

In this section, we summarise known Java installation issues and implications of up-grading to the latest versions of Java. Other known issues with Java that do not affect installation, but can cause a hang with no Omniscope error messages are listed here.

Java permissions and security issues

Java has security settings which may affect the treatment of images. If user settings restrict access to certain packages in particular the sun.awt.image package within Java then certain views can be affected. The following issue has been seen before:

java.security.AccessControlException {class java.security.AccessControlException "access denied (java.lang.RuntimePermission accessClassInPackage.sun.awt.image)"
at java.security.AccessControlContext.checkPermission(Unknown Source)
at java.security.AccessController.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPermission(Unknown Source)
at java.lang.SecurityManager.checkPackageAccess(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)

It is likely that your security policy is not letting you access to classes in java.awt.image packages.
Access to classes in AWT package, viz., and the java.awt.image packages are required.

In order to fix this problem you need to grant Omniscope users permission by adding the following statement

grant {
permission java.lang.RuntimePermission
"accessClassInPackage.sun.awt.image";
}

to any of the security policy files referred to by statements such as

policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy

in the java security configuration file for your installation. This file should
be located at ${java.home}/lib/security/java.security.

${java.home} refers to where java is installed i.e. "C:\j2sdk1.4.2_14".
${user.home} refers to user home directory which on Windows is "C:\Documents and Settings\<user>" where
<user> refers to the user name. For example use named David, user.home would be "C:\Documents and Settings\David"

Known Java on Vista issues

The Windows Vista operating system is not fully supported in Java versions 1.4, Java 1.5 releases prior to build Java 1.5.0_11 (Java 1.5.0_11 or later supports Vista), or Java 6 original release or 1.6.0_01 (Java 1.6.0_02 or later supports Vista). If you are running a Java version not fully supported on Vista please update to the latest release of Java at http://www.java.com or use the PVM version bundled with our applications (Java 1.5.0_11).

International fonts

Some fonts can crash earlier versions of Java and this has been fixed in latest releases of Java. Visokio applications have been modified to minimise the impact of this rare problem in the event you are running older versions of Java.

Java Daylight Savings Time (DST) Compliance

Omniscope, DataPlayer Studio and FeatureFinder are Java applications so their compliance with DST (as recently updated) depends on the Java VM used.

http://java.sun.com/developer/technicalArticles/Intl/USDST/ provides details on Java version DST status.

Our products are available both with and without a bundled private Java VM. The current bundled installers of Omniscope 2.2 and FeatureFinder 1.3 available on our website all use Java 1.5.0_11 which is DST compliant.

Other bundled installers available on our website (such as FeatureFinder 1.2, and Omniscope installers built before Feb 26th 2007) may not be DST compliant. If DST compliance is critical and you cannot upgrade to newer product versions, you must use the non-bundled installer.

If you use a non-bundled installer, it is up to you to ensure the system Java VM is compliant.

Non-Windows Installs

Non-Windows Installation

This section deals with issues relating to installation on operating systems other than Microsoft Windows.

• Apple OS X10.3 or later
• Linux
• Solaris/Unix flavours

Visokio Omniscope is also available as a JAR file for any operating system

Proxy Settings

Proxy Settings

If you are in a typical medium to large organisation, your PCs may access the Internet through a proxy server. Proxy servers are separate computers that act as gateways and are used to improve security and efficiency.

At present, due to limitations in Java, Visokio applications cannot detect your proxy settings automatically in certain cases.

In order to access some Visokio services, including activation, automatic updates and sending bug reports, each Omniscope installation must be configured with the organisation's correct proxy settings. Your system administrator should be able to provide you with the settings. Regardless of your deployment/update strategy, if Visokio installations are to be activated by their users, proxy settings may need to be deployed.

Depending on the way proxy settings are configured in your organisation, Visokio functions might "just work" automatically. To test this, install on a trail machine and attempt to activate using a trial key (contact us to get one). If activation fails, you can enter the correct proxy settings manually, but it is recommended you automatically deploy these proxy settings when rolling out. At present, this is best done using a plain-text proxy settings property file, deployed into the \Visokio Omniscope (or FeatureFinder Web) program folder.

Configuring proxy settings manually

• You will need to know the http proxy host and http proxy port of your proxy server
• Start Omniscope/DataPlayer Studio/FeatureFinder
• From the Tools menu, open the Advanced tools submenu and choose HTTP proxy settings...
• In the dialog, tick the Use HTTP proxy box and enter the host and port settings
• Click OK

Configuring whilst activating

When activating Omniscope, if the necessary proxy settings are absent, Omniscope will ask you to enter these as part of the product activation dialog steps. When the Online activation failed dialog appears, click the Proxy settings button and enter the details, as described above.

Configuring proxy settings automatically

If you are a system administrator and are deploying (rolling out) Omniscope to multiple PCs, you can simultaneously roll out proxy settings. This is useful because it allows your deployed installations to be activated by your users without any further configuration (apart from a valid license key/serial number).

• Use a single test installation of Omniscope and configure the correct proxy settings as described above
• Open the folder {System drive}\Program Files\Visokio Omniscope
• You will see the file proxy.txt which contains the proxy settings you have entered, which will be similar to:

                   #Resource properties file
                   #Wed Feb 15 13:37:09 GMT 2006
                   http.proxyPort=80
                   http.proxyHost=proxy.visokio.com

• Deploy this file to the same folder in your deployed Omniscope installations

Known Activation Issues

Known Activation Issues

Reverting from version 2.4 to 2.3

If you are reverting your Omniscope 2.4 installation to Omniscope 2.3 installation it is important that you deactivate your license prior to installing version 2.3. If you are upgrading from Omniscope 2.3 to Omniscope 2.4 then this does not apply and you do not need to deactivate prior to upgrading.

If you have any questions please contact us using our contact form.

Back to Activation

Hang Diagnosis

Hang Diagnosis Procedure

In the event of the application hanging (freezing, so no user interaction is possible), please use the following procedure to send a hang diagnosis to Visokio (Windows PCs only). Although these steps may seem complex, this will help us greatly with what can be a difficult problem to diagnose. For assistance please contact us.

Creating and sending a hang diagnosis

1. Using Windows Explorer, navigate to the program installation folder
   (usually "C:\Program Files\Visokio Omniscope")
2. Double-click "launch_console.exe"
3. In the black console window:
   1. Click on the black "C:\" icon in the left of the title bar.
   2. Choose Properties from the menu that appears.
   3. In the layout tab, ensure "Screen Buffer Size" has a large value such as 300 in the Height field.
   4. Click OK
4. In Omniscope, open the bug report dialog (triggering the hang)
5. Switch to the black console window
6. Press Ctrl+Break (diagnostic information will be generated)
7. Click on the black "C:\" icon again and choose "Select All" from the "Edit" submenu.
8. Click on the black "C:\" icon again and choose "Copy" from the "Edit" submenu
   (this will copy the diagnostic text to the clipboard)
9. Paste this into the "Detailed information" field in the Software Issue Report submission page. Complete the other fields as indicated and click "Submit".

Forcing the application to quit (Windows)

1. Press Ctrl+Shift+Esc (simultaneously). Task Manager will appear.
2. In the first tab ("Applications"), right-click the hung application. Be careful to make the correct selection.
3. In the menu that appears, choose "Go to process". An entry inside the "Processes" tab will be selected for you.
4. Click the "End Process" button.
5. Click "Yes" to confirm.

Omniscope Scaling

Managing Omniscope Scaling & Performance

File sizes & typical RAM requirements

How much data can Omniscope handle? Omniscope software has no fixed upper limit on the number of rows and columns that can be managed in a single file. The effective upper limit depends on the specification of the machine running the Omniscope file, and a complex relationship between processor speed, available Windows and Java memory addressing, data types, density of the columns and the number and type of Omniscope views employed in a given file. Effective Omniscope data volume is principally related to the number of cells (rows x columns), while the effective capacity of a computer (for this purpose) is principally related to the addressing space and amount of RAM in the machine. The best way to determine how large data sets (over 5 million cells) or very large data sets (over 15 million cells) will perform in machines with different amounts of RAM is to try it with Omniscope Professional, or request an Enterprise trial key to use more powerful 64-bit servers with more RAM.

In general, a recent 32-bit computer with:

• 512 KB of RAM should handle files of about 5 million typical cells
• 1.0 GB of RAM should handle files of about 15-17 million typical cells
• 2 GB of RAM should handle about 20 million typical cells
• Over 2 GB of RAM cannot be used by 32-bit systems, only by 64-bit systems

The less than proportional increase between 1.0 and 2.0 GB of RAM results because the 32-bit Windows/Java addressing limit is reached at about 1.2 GB...well before the 32-bit computer can utilise its full  2.0 GB. Computers running 64-bit operating systems with 2.0 GB or more of RAM will have much higher limits.  We have documented files of 8 million rows and 15 columns (120,000,000 cells) running on 64-bit servers with 8 GB of RAM, and some prototyping installations are currently using up to 16 GB of RAM.

Running on 64-bit Platforms

A 64-bit version of Omniscope is now available.  More info.

Hidden columns 

If you are dealing with very large data sets, or plan to distribute very large Omniscope report files to desktop machines with 256 MB or less of RAM, you can minimise peak Omniscope memory use by hiding all unused columns (use Edit > Manage Fields > Hide Field). A data field (column) is not loaded into memory until it is actually displayed, so opening views that display many fields, like the Chart View and the Table View, should display only the most useful fields. Fields rarely needed for filtering should be shown in views only on Report Pages for users who need to view and filter by the values in that field. Users who never open these Report Pages will have lower peak RAM requirements and better performance.

Omniscope includes tools to help analyse memory use and optimise very large files for a range of recipient machines. These tools are documented here.

Impact of Views employed

The use of certain views limits scalability and performance in the upper reaches of file size. Omniscope performance in some views is also sensitive to the number of unique category values being used in the view.

Tree View:  this view is not currently architected for very large data sets. If you do not need it, you should hide this view so that users are not tempted to try it with very large data sets.  If you need to use the Tree View with very large data sets, please contact us for assistance.  Future versions will perform better.

Pivot View: currently does not handle very large numbers of categories well, especially on slower processors. If you encounter slow performance, try reducing the number of unique categories used in the Pivot View by setting wider category limits ( 'buckets' ).  Future versions will perform better with more unique categories. For more information, see Pivot View Data Truncation.

Back to Scaling & Performance 

DataPlayer Scaling

Flash .SWF DataPlayer Scaling and Performance

The maximum number of records that will perform well inside a DataPlayer is evolving along with Flash itself. The effective upper limit depends on the size and character of the data set (number of cells= rows x columns), and the configuration of the DataPlayer. In general, DataPlayers containing 5,000 records or less will perform very well on most modern machines. Depending on content and configuration, 10,000 record (and beyond) DataPlayers are possible. We are in the process of re-writing underlying code in ActionScript 3, which should dramatically increase the scaleability and performance of DataPlayers by early 2009.

The best way to determine how your data will perform with various record counts inside the DataPlayer is to use the free 30-day trial of Omniscope Professional to make some samples for testing.

Large Scale Examples

This section provides some links to working examples of DataPlayers containing relatively large record sets, together with some hints regarding performance optimisation in the data and settings necessary to accommodate relatively large numbers of records.

Bonds Example: 20 columns x 6,241 records = 124,820 cells

Arguably, this demo really has too many columns to be useful, since the values in most of the columns are not used for selecting, only shown in details. The record details could just as easily be shown on linked pages, rather than embedded inside the Flash file. This demo is displayed here for reference only.

This demo normally loads without warning notices and runs well in most recent browsers. However, when loading this page, some older browsers and less powerful machines may see a notice (sometimes repeatedly) from the Adobe Flash plug in:

"A script in this movie is causing Adobe Flash Player 9 to run slowly. If it continues to run your computer may become unresponsive. Do you want to abort this script?" If the user presses No, (sometimes repeatedly) the loading will continue and the DataPlayer should eventually display:

Back to Scaling & Performance

ODBC & JDBC

ODBC and JDBC

ODBC and JDBC are industry standard protocols for connecting directly to tables and views in relational databases. It is relatively easy for you or your Database Administrator to connect Omniscope to databases directly using the Omniscope Database Connectivity wizard and either ODBC or JDBC. Omniscope can import the results of any SQL statement/query that returns a table using either protocol. Using ODBC it is possible to connect to tables/reporting views drawn from only one database. Using JDBC, it is possible to connect to joins of tables/reporting across multiple databases. In general, JDBC connections perform somewhat better than ODBC.

ODBC - Open Database Connectivity provides a standard software API method for using database management systems (DBMS). The designers of ODBC aimed to make it independent of programming languages, database systems, and operating systems.  For more detail, see Wikipedia

JDBC - Java Database Connectivity is an API for the Java programming language that defines how a client may access a database. It provides methods for querying and updating data in a database and is oriented towards relational databases. The Java Platform, Standard Edition includes the JDBC API together with an ODBC implementation of the API enabling connections to any relational database that supports ODBC. For more detail, see Wikipedia

For more detail on how to connect Visokio applications directly to one or more databases using ODBC and JDBC see Connect to Databases.

Connect to Databases

Connecting to Databases

Omniscope includes a Database Wizard to help establish direct connections to database tables and reporting views. Omniscope will import the results of any SQL statement/query that returns a table. The Omniscope Database Wizard is accessed via the File > Connect to database command, documented here.

In order to connect directly to a database, rather than importing a .CSV or .TSV data file exported from a database, you need to know the type of database and its connection details. Using the Visokio Database Wizard, you enter the connection details for your database and choose which database table or reporting view you wish to retrieve data from. By default, this will create a persistent linked data source relationship between this database table/view and the .IOK (Omniscope) files you are creating.

If you connect via ODBC, you can access multiple tranactional tables, but only one database.  If you connect via JDBC, you can retrieve data from multiple tables in multiple databases, and performance will also be better.  If you do not know how to write the SQL query that assembles the reporting view you want to import into Omniscope, ask your Database Administrator to add the query in Omniscope so that every refresh re-creates the reporting view, drawing the latest information from multiple transactional tables within the database(s) to create a single, 'flattened' tabular view of the data for scrubbing, analysis and reporting.

Suggestion: Database tables are operational and transactional in nature. They are usually not intended to be shared with humans without some translation of the codes used in the tables. Rather than access a transactional table, try to use a reporting view that also translates obscure codes and other internal values to values meaningful to the humans receiving your reports. Also, it is better to include every record in the view, rather than making  too many pre-selections in the query assembling the reporting view. Errors in fields can result in some records not being included in the view if you are being too selective when assembling the reporting view. First try just dumping everything (people and all data linked to people, places, things etc.) into a few large reporting views extracted from the database(s). Open these views in a scalable visualisation  tool like Omniscope, then correct/scrub and filter/hide unwanted data visually. Also, speak to your database administrator about using corrections exported from Omniscope to help correct erroneous fields in the source database.

Warning: Preserving Changed and Merged Data- Omniscope does not currently support partial refresh from database tables/views. Linked data sources overwrite all the data in a given .IOK or .FFC file with data from the linked source only. If you have changed data manually, or imported columns of data from other sources, such as spreadsheets or departmental or personal databases, your changes will be lost on file refresh.  If you are using Omniscope to merge data from other sources, keep your merged data and commentary in a separate .IOK, .CSV or .XLS "merge file" to avoid those values being lost every time some of the data is refreshed from a linked source.  For more detail on using merge files to protect data from different sources, see  File > Import into current file > Merge data from another file in the Omniscope User Guide.

Connecting via ODBC

ODBC is a technology for connecting to most databases and requires you to set up a named ODBC data source in Windows. This is the approach needed to connect to an Access .mdb database, for example.  In Windows XP, go to Control Panel, Administrative tools and choose Data Sources. Click Add, choose the Access driver (or otherwise, depending on your type of database), choose the appropriate .mdb file and enter a suitable Data Source Name. Open the Omniscope Database Wizard under File > Connect to database and follow through the steps.

Connecting via JDBC

If you have a database such as Oracle or PostgreSQL, or wish to customise the database import behaviour, you can connect via JDBC using a JDBC JAR driver file obtained from the database vendor or 3rd party. This may need to be specific to your database version as well as vendor. You will need to know how to construct the "JDBC URL" for your database.

In the Database Wizard, choose JDBC and enter the JDBC JAR driver path such as:
"C:\Program Files\MyDatabase\Java\JDBC.jar", and the JDBC URL such as "jdbc:mydb:products".
Enter the username and password, if necessary, and choose the table or view you want to look at.
On the next page, you can customise the SQL statements, allowing you to JOIN multiple tables on the fly. Only change these values if you are familiar with the implementation of SQL for your database vendor and version. Finally, when connecting via JDBC, you can rename fields at import time, on the last page of the wizard, allowing you to change unreadable fields such as "CUST_ADR" to more reader friendly "Customer Address".

Guided examples of JDBC database connection parameters:

• MS SQL Server 2000 & 2005 using JDBC
• Oracle version 10g using the Oracle Thin JDBC driver
• Oracle version 8.1.7 using the Oracle Thin JDBC driver

Working with databases

Saving the connection and refreshing

To save the connection details you have entered into the Database Wizard for subsequent refreshes, save the current file as an .IOK or .FFC file using File > Save as.... The new file will contain a highly-compressed snapshot of the data as it was when imported, plus all the database connection parameters you entered into the Wizard. Next time you open your file, you will see the old data, but you can refresh from the database view specified in the Wizard by choosing File > Import into Current File > Refresh from source.

Setting Field (column) data types

Unlike text-based data file import (such as .XLS or .CSV), Omniscope and DataPlayer/FeatureFinder do not automatically recognise and convert data drawn directly from databases upon import. Instead, the data type descriptions of the fields in your database are relied upon to determine data type in Omniscope and DataPlayer/FeatureFinder. If your database declares the field "CUST_AGE" as Text ("Char", "String" or "Varchar"), Omniscope will treat it as Text also. To avoid the need for manual changes, you must structure your source database correctly by declaring the field "CUST_AGE" as a numeric field (for example).

Editing data from databases

At present, database connections in Omniscope and DataPlayer/FeatureFinder are only one way, i.e they only import a copy of the data in the database table/view. You can make edits but cannot submit your changes back to the database table automatically. If you plan to edit data from databases in Omniscope or DataPlayer/FeatureFinder, you will need to agree a way of submitting your changes back to the database administrator (such as exporting a .CSV or .XML file and having the Administrator use some simple tools to import corrections made in Omniscope back to the database).

Warning: Preserving Edits- If you make changes to your .IOK/.IOM file, such as correcting the data type of a field, or editing data values, or adding/deleting records (rows), and you have not submitted the changes to be made back to the database administrator, your changes will be lost if you later refresh from source (see Saving the connection details, above). You can prevent accidental Refreshes from source by ticking Unlink from source in the File > Export > Export data dialogue, but this will also remove your database connection parameters from the .IOK file.

The above means that if you add, delete, rename or convert fields, these changes will not be applied to the source database unless you export a copy of the changes and discuss them with your Database Administrator. In the meantime, you will need to keep a record of your changes if you want to refresh from source. If these changes include new fields/columns which are not implemented in the database, you may need to create 2 files...one which is refreshed directly from the database, and one which you merge in yourself because it contains new or corrected fields/columns which are not carried or corrected in the database. There needs to be a column common to both files to enable you to merge them automatically...see the discussion under File > Import into current file > Merge data from another file in the Omniscope User Guide.

Connection Caching

Database Connection Caching

Since Omniscope 2.3, database connection caching is supported. This is mainly of use in server installations, and should be ignored for typical desktop use as it will provide little benefit.

Connection caching allows an Omniscope instance to retain and reuse database connection objects, which can improve performance.

By default, desktop Omniscope installations cache 1 connection for up to 5 minutes after use.

Connection caching has the following options:

* Use zero for these options to disable caching - connections will be created and discarded immediately before and after use. The numbers in brackets are the defaults used when the Omniscope process is in headless / silent mode.

These options can be configured by editing installconfig.properties in the installation folder (typically C:\Program Files\Visokio Omniscope) and adding/changing the ADDITIONAL_JVM_ARGS property. For example, the following turns on debug output and a 2 second expiry:

ADDITIONAL_JVM_ARGS=-Dvisokio.dbcc.debug=true -Dvisokio.dbcc.maxage=2000

If you are running Omniscope Enterprise tools as a service, you instead need to edit "C:\Program Files\Visokio Omniscope\service\wrapper.conf", by adding lines such as:

wrapper.java.additional.1=-Dvisokio.dbcc.debug=true
wrapper.java.additional.2=-Dvisokio.dbcc.maxage=2000

Restart the service after making changes. Warning: at present this "wrapper.conf" file is overwritten on re-installation of Omniscope. Look in "wrapper.log" for debug output when running as a service.

Back to Database Connections 

Knowledge Base Top

ODBC without DSN

Using ODBC without DSN (Data Source Name)

The Omniscope Database Connection wizard supports ODBC data sources. Normal use of ODBC connections entails configuring an ODBC data source on each client PC requiring connectivity to the database for refresh. In Windows XP, for example, this configuration is done on the client using Control Panel, Administrative Tools, Data Sources. When distributing an .IOK file to numerous desktops within an organisation, if 'refresh from source' functionality is desired, this could require the same ODBC data source to be manually configured on every PC... potentially time-consuming for central administrators

Fortunately, it is possible to configure a "DSN-less" ODBC database connection within Omniscope. This encapsulates the full database connection parameters within the IOK file, and (providing the ODBC database driver is available) requires no administration on each client PC. This allows Omniscope to refresh data from the underlying database automaticallywhenever the .IOK file is opened on the client PCs. Omniscope can also be refreshed by users 'on-demand' using File > Import into current file > Refresh from source.

DSN-less ODBC Configuration 

Start Omniscope, and choose File > Connect to database. The Database Connection Wizard will open. Select ODBC and click Next. You will see the ODBC configuration page with the field Data Source Name.
Normally, when using a user- or system- configured ODBC data source, you would enter the name of the data source (the DSN) here. Instead, to avoid configuring the data source on all client machines,
you must enter the full DSN-less ODBC connection string. This is a line of text containing name=value definitions separated by semi-colons. Any values containing spaces are enclosed in curly braces. This describes the parameters of the ODBC data source.

For example, to connect to a sample Access database, you might use the following in the Data Source Name (DSN) field:

DRIVER={Microsoft Access Driver (*.mdb)};DBQ=C:\db1.mdb

Discovering the Connection String

• On a typical client PC, open Control Panel -> Administrative Tools -> Data Sources.
• Select the File DSN  tab and click Add.
• Select the appropriate driver (e.g. "Microsoft Access Driver (*.mdb)") and click Next
• Click Browse and choose where you want to save the .dsn file (this is a temporary file you are going to delete later).
• Click Next then Finish.
• You will be shown the vendor-specific ODBC setup dialog. For example, with Microsoft Access, you might only need to click Select and browse to an existing .mdb file before clicking OK.
• Browse to the location of the .dsn file and open using Notepad.

[ODBC]
DRIVER=Microsoft Access Driver (*.mdb)
UID=admin
UserCommitSync=Yes
Threads=3
SafeTransactions=0
PageTimeout=5
MaxScanRows=8
MaxBufferSize=2048
FIL=MS Access
DriverId=25
DefaultDir=C:\
DBQ=C:\db1.mdb

To convert the above to the full connection strring:

1. Omit the first [ODBC] line
2. Put curly braces around all values containing spaces
3. Put all name=value pairs on one line, separated by semicolons.

This gives you the full connection string. In this example, the string becomes:

DRIVER={Microsoft Access Driver (*.mdb)};UID=admin;UserCommitSync=Yes;Threads=3;SafeTransactions=0;PageTimeout=5;
MaxScanRows=8;MaxBufferSize=2048;FIL={MS Access};DriverId=25;DefaultDir=C:\;DBQ=C:\db1.mdb

Note: This is more verbose than absolutely necessary, the following will suffice, in this example:

DRIVER={Microsoft Access Driver (*.mdb)};DBQ=C:\db1.mdb

Finally, paste this connection string into the ODBC Data Source Name field of the Omniscope Database Connection wizard, as described above.

Examples:

The following examples have not been verified:

Oracle: DRIVER={Oracle ODBCDriver};UID=Kotzwinkle;PWD=whatever;DBQ=instl_alias;DBA=W

AS400: Driver={Client Access ODBC Driver (32-bit)};System=myAS400

Excel: Driver={Microsoft Excel Driver (*.xls)};DriverId=790;Dbq=c:\somepath\mySpreadsheet.xls;DefaultDir=c:\somepath

SQL Server: Driver={SQL Server};Server=MyServerName;Database=myDatabaseName

References

http://www.asp101.com/articles/john/connstring/default.asp (scroll down to ODBC DSN-less)

www.oracle.com/technology/docs/tech/windows/odbc/htdocs/817help/sqoraFormat_of_the_Connection_String_.htm

http://www.databasejournal.com/features/mssql/article.php/1491011

Publishing .SWFs

Publishing Flash DataPlayer .SWFs on the Web

Omniscope DataPlayer & Enterprise Editions export web-ready file structures (with minimalist HTML display page) containing the DataPlayer .SWF files ready for display on the open Internet.  DataPlayers produced by licensed copies of Omniscope can be displayed on any inter/intranet domain. DataPlayers produced by FeatureFinder Web will display on nominated domains/sub-domains only.

Note on managing images: Although DataPlayer .SWF files can incorporate images for use in Tile View, they will be fixed in size and often reduced resolution. The original, higher resolution images can also be displayed on the web in the DataPlayer Details View, but only if the entire folder containing the original, larger/higher resolution images is also uploaded to the web server in the same relative directory location as when the image set was originally specified in the .IOK configuration file from which the DataPlayer was exported.

Export File Set

Once you have configured an Omniscope DataPlayer .IOK project file, previewed the .SWF on your desktop and saved all your configuration settings in the .IOK data file, you are ready to export your DataPlayer SWF file set for display on the web.  Just click the 'Save for Web' button on the Save Settings and SWF page. When you click 'Save for Web', the DataPlayer is exported within a web-ready file structure with a minimalist HTML display page in the top level of the directory structure.

Copy and Edit Top Page

Once DataPlayer/FeatureFinder Studio has finished exporting the web file set containing the DataPlayer, open the resulting HTML display page (bearing the name of the project, in the top directory of the file structure) with a standard HTML editor such as Adobe DreamWeaver or Microsoft FrontPage. You will see that the exported display page is minimalist, with only enough mark-up to display the DataPlayer .SWF in a browser. The minimalist page has none of the final HTML layout, scripting or content (with which you or your web master will want to surround the DataPlayer) for display on the web.
 
Suggestion: Good practice at this point is to make a copy of the top-level, minimalist HTML display page, change its name and put the copy into the same location alongside the original. From then on, only paste your own mark-up, scripting etc. into the re-named copy. This way, if you modify the DataPlayer and re-export its file set, the original minimalist display page is overwritten, not your own elaborated version. The underlying DataPlayer files referenced in your own version of the display page are all updated, and they are still referenced properly assuming their relative position in the directory structure has not changed.

Upload

When you are happy with the look of both the DataPlayer and your own HTML mark-up and scripting surrounding it, upload the entire file set and the original images folder (if any) to your web server (preserving the directory structure).

Warning: If you are using UNIX/LINUX web hosting, remember that all file names/references will be case-sensitive. Check all the references in the files produced by Omniscope against your own namings to make sure that upper and lower case is being used consistently in the file names and all references to the files.

Web Server Configuration

Publishing .IOK files on Web/CMS Servers

MIME type configuration

Extension: .iok
MIME type: application/vnd.visokio.omniscope-iok   (or use the generic binary mime type application/octet-stream if this causes problems)

Example: Configuring Microsoft Internet Information Services (IIS)

1. In IIS Administrative Console snap-in, right click the entire server and select Properties.
2. On the Internet Information Services tab, click the MIME Types button.
3. Add a new MIME type.
4. In the Extension box, type ".iok" (without the quotation marks), and then in the Content type (MIME) box, type "application/vnd.visokio.omniscope-iok" (without the quotation marks).
5. Click OK, and then restart IIS.

Server software known to require configuration:

• Microsoft Content Management Server (configured in IIS, as above)

Server software known NOT to require configuration:

• Apache 1
• Apache 2

Knowledge Base Top

Applet Limitations

Applet Limitations

Background

Insurmountable problems

Memory

Memory requirement in Omniscope is the result of a complex equation depending on upon data complexity, view configuration and use case. Omniscope was built to leverage the higher memory capacity of relatively modern PCs to provide a rich data navigation experience.

Applets are limited to 128mb of memory which, as a very rough guideline, may be enough to navigate smaller files with limited views. The only true way to find the applet memory limit for a particular type of data is to experiment with data size in terms of records and fields. 

Life-cycle Issues

"Life-cycle" is the manner in which an applica