Previous Topic

Next Topic

Book Contents

Book Index

SQL Server

Edition compatibility

SQL Server Express, Standard and Enterprise are all acceptable. VSys does not require its own SQL Server installation or even its own instance, and will work correctly with other applications on a common server.

Hardware requirements

VSys has very low requirements on your SQL Server 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 SQL Server. It does not require its own application server either, as it's a simple two-tiered client-server setup thick Windows client with SQL Server as the backend. VSys can also be used in a Citrix or Terminal Services environment.

Setup

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 SQL Server accounts, or providing rights via Active Directory. All users in the end need the same basic sets of permissions, and VSys does not use SQL Server'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.

All VSys One users must have 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. CREATE and ALTER rights may be needed occasionally 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.

Best practice: give users db_ddladmin rights on their database.

When creating a SQL Server database to be used by VSys, you have several options.

Option

Preferred value

Additional information

Collation

Latin1_General_BIN

 

Recovery model

Simple

Other models are valid but will use unnecessary amounts of disk space and are not used by VSys.

Compatibility level

Any value is valid here.

 

Autogrowth

Enable Autogrowth and Unrestricted File Growth must be selected.

 

Advanced notes

For VSys One to work correctly, SQL Server requires that the VSys One tables be owned by "dbo", not the person who created them. You can see table ownership within SQL Server Enterprise Manager – just open up the database where your VSys One data is stored, then open up Tables, the owner will show in a column next to each table. To change it, right-click on the table, select Design Table, right-click on any field and then click on "Properties". Change the owner, then click on Close. Click on the Save icon to save your changes, then continue on to the next table. (The VSys One installer and VSys One itself will automatically make all new tables owned by "dbo".)

VSys One requires that certain columns use case-insensitive collation orders. When VSys One creates tables, it will specify the collation order for these columns as Latin1_General_BIN. Don't change this: VSys One will fail miserably but silently on many lookups if you do.

SQL Server 2008

When connecting to a SQL Server 2008 database, it's critical that the Server address value is the server's canonical name, e.g. "SS2008A" rather than just its IP address. When there are multiple instances of SQL Server running, Server address must be the server's canonical name + backslash + the instance name, e.g. "SS2008A\VSysInstance".

See Also

Database-Specific Notes

Oracle

NexusDB

Installing NexusDB Server

Configuring NexusDB Server as a Windows Service

Table rebuild tool