Prior to WRDB 5.0, only one "data provider" was supported: Paradox. A data provider refers to both the type of database server or file format the data will be stored in and the software (or drivers) used to access that data.
There are three types of data providers used by WRDB:
Client-server: databases are stored on a remove server (e.g., Oracle, SQL Server, Firebird, MySQL). These data providers are very high performance (if you have a fast LAN or Internet connection), but can be difficult to set up and administer. They are the only providers that give you reliable simultaneous multi-user access to databases.
File-based: data are stored in a single file on your computer (e.g., Access, Firebird Embedded, SQLite). These will generally give poorer performance and be suitable for smaller projects, but they are ideal for stand-alone projects that don't need to be simultaneously shared with others. They are easy to set up.
Directory-based: tables are stored in separate files; database is directory (e.g., Paradox). This is the format used by earlier versions of WRDB but is deprecated however you can still import and export data from and to Paradox files.
Table Storage: Paradox was unique in that tables stored in multiple databases (e.g., subdirectories) could be simultaneously accessed; that is, you could "join" tables from multiple directories to create reports, etc. (e.g., to connect the Station ID to the Station Name). Consequently, earlier versions of WRDB were designed to segregate tables into Working, Master, Shared Support, and Project Support directories, each containing multiple tables. Using Paradox Runtime and BDE, it was possible to have multiuser access by placing the tables on network drives (and configuring BDE appropriately).
All modern databases are more restrictive (two steps forward, one step back): you can only join tables contained in the same database, and file-based providers (including Paradox), have limited ability for multi-user access.
Note: although this is also true for the new Paradox provider, WRDB simulates the former behavior by copying Support tables as needed to perform join operations and then deleting them. This adversely affects performance, but maintains a high level of backwards compatibility.
Therefore, all Working, Master, and Support tables are stored within the same database. This imposes the following limitations compared to earlier versions of WRDB:
All table names within a project must be unique because you cannot separate them into subdirectories.
You cannot use Windows Explorer to manage your tables (e.g., moving, copying, and deleting).
If multiple projects are stored in separate databases, they cannot share Support tables in real time (i.e., with constant synchronization). If you want to share Support tables, you need to either store multiple projects within the same database, or manually synchronize the Support tables when they change.
The following features have been developed to mitigate the above limitations:
The Database Explorer has been developed to help you manage your databases, including features to copy, rename, delete, import, export, and merge tables.
The Tracking table has been enhanced to allow you to assign table group names which can be used to filter the table list when there are large numbers of Working tables. See WRDB Projects, Tables, and Databases.
See also Data Provider Implementation Notes and Choosing Your Data Provider