WRDB Projects, Tables, and Databases

A WRDB Project is simply a container for specifications regarding the database type and location and a few project preferences (see Project Preferences). A list of all WRDB Projects that you have configured is contained in a required file called WRDB.ini. By default, a special directory under the <My Documents> folder of your computer is created called WRDB and the WRDB.ini file is expected to be found there. If it is not, a First Time Installation form appears so help you get started.

You may wish to share the project list in the WRDB.ini file with others in your workgroup so that you don't have to manually create individual project connections for each person. Do this by clicking the Config button on the Open & Manage Projects form. This will allow you to specify a network share where you will place the WRDB.ini file that everyone can use.

The project database contains a variable set of Working and Master tables, and standard set of Support tables.

In earlier versions of WRDB (and when using the Paradox data provider in WRDB 5.0), each table was stored in a separate file (or set of files, if the table was indexed), and the files were stored in directories. This allowed the user to utilize Windows Explorer to manipulate tables and databases. This file-based method of database management is antiquated and rarely used anymore.

Modern data providers use either a single database file which contains all tables, indices, views, constraints, etc. (for example, Microsoft Access), or a database server which responds to remote queries from database clients and similarly stores all objects in a single file on a remote server (for example, Oracle). This different paradigm has cause some redesign in WRDB 5.0.

Whereas Paradox was easily able to use multiple directories (e.g., Working, Master, Shared Support, and Project Support directories), with some being shared between projects and users, the new paradigm requires that all project tables reside in the same physical database.

The difference between how multiple projects (CoosaNat and CoosaCal) share Support tables is best shown in diagrams:

When deciding how to manage multiple projects using WRDB 5.0, you need to decide how you want Support table (e.g., Stations and PCodes) data to be shared. You have two choices:

  1. Use multiple databases and manually synchronize selected Support tables: when two projects use different databases (either using the same of different provider types), when you add a PCode in one project it will not automatically be added in another. You can keep them synchronized by manually retyping the entry, of by using the Database Explorer to copy the contents of the PCode table across projects (see Copy From). This scheme will work fine if you have developed a static set of PCodes and don't need to share Station IDs across projects.

  2. Store multiple table groups in the same database so that all Support tables are shared: this will ensure that all table groups share the same Support tables and thus automatically kept in sync. Working tables are assigned to table groups using a new field in the Tracking table called Table_Group (this is illustrated in the second diagram above).

Although it would technically be possible to store WRDB 5.0 data in Paradox tables, it raises some serious technical complications which results in very poor performance. Use of Paradox tables as a data provider is therefore no longer supported. Instead, you should create a new project using another data provider (like SQLite or Oracle) and run the WRDB 4.5 Upgrade Wizard to import all the data from the old Paradox tables into your new database.