Oracle

Users

VSys has been validated on Oracle 9i and 10g. It has not been validated on Oracle 11g or higher, though it may well work in that environment.

In general, it's far simpler to have all VSys One users share a common database login ID and password rather than assigning them all their own unique accounts. All users in the end need the same basic sets of permissions, and VSys does not use Oracle's permissions to limit what actions individuals can perform, instead it does that authorization internally due to the complex nature of table and data interactions.

CREATE and ALTER rights may be needed when upgrading versions, as VSys occasionally makes changes to its expected database schema. DROP rights are only ever needed for data restores when tables already exist or for special schema updates in which one or more tables need to be built from scratch and then repopulated.

Hardware requirements

VSys has very low requirements on your Oracle installation. It does not require a dedicated machine, or even its own instance, just a single database to call its own. We recommend 512MB of memory, and fast disk is helpful but not mandatory. In general the working set will be under 100MB of data, and the full database under 1GB. High availability is generally not required, as volunteer management is rarely considered to be mission-critical, so server redundancy is not necessary.

VSys will happily run on a virtualized copy of Oracle. It does not require its own application server either, as it's a simple two-tiered client-server setup thick Windows client with Oracle as the backend. VSys can also be used in a Citrix or Terminal Services environment.

Synonyms

Oracle stores its tables as owned by individual users. The syntax for referencing tables which are not owned by the current user would break VSys One's methods of accessing tables in other systems (SQL Server, NexusDB), and so VSys One uses Oracle synonyms to make it look to the calling application like the tables owned by another user are local to the current user.

To do this, VSys One does a few tricks:

1. It names tables under Oracle in all upper-case (they're all lower-case on other systems).
2. For every user who logs in, VSys One creates a table synonym in lower-case to each table, even if the logged-in user owns the table. This allows VSys One to reference the table as lower-case, regardless of the ownership of the data.

This means that all VSys One users must have:

1. At least SELECT access to all VSys One tables. Lacking INSERT, DELETE or UPDATE rights may cause aspects of VSys One to not work as it attempts these operations.
2. The rights to create and drop synonyms.

If you really know what you're doing, you can disable synonym creation. Find the appropriate section in the ini file which corresponds to the connection you want to adjust, then put in the value

opt:nosynonyms=Y

If you do this, VSys One will expect that the tables are named in lower-case and are owned by the currently logged-in user.

Locking

VSys One uses the dbms_lock package in order to provide cooperative locking among sessions. It is therefore important that all users be granted execute rights to that package. From an Oracle prompt:

grant execute on dbms_lock to YOUR_ORACLE_USER;

Do this for every Oracle user who will log into VSys One.