Posted 59 months ago on 6/12/2008 and updated 2/15/2009
Take Away: Overview of why using BDE aliases are a good idea.
A problem with working with data that can come up is moving data after you've developed forms, queries, and reports that use them. If you don't use aliases, moving data from one location to another can be a problem. If you developed an application and moved the data, you had to redefine all your links (a link establishes a relationship between tables by connecting corresponding fields). If you moved one of the tables to another directory path, you created a big problem. The usual solution was to break and then create the link again. An alias is the name you assign to a directory path and implement to solve this problem. Paradox uses aliases to refer to a location of files, such as a directory. You manage your aliases by selecting Tools | Alias Manager. In addition to using two types of native drivers (file-based and server based), you can use ODBC drivers with the BDE.
Note Aliases are also used to connect to a specific database on a SQL server using either the BDE's native drivers or ODBC. In other words, if you want to work with non-Paradox tables, alieases help you do that more easily.
In Paradox table terms, the location that is pointed to by the alias often is called a database. Although aliases might be new to you, they are a great time-saver. They make using hundreds of tables, queries, and forms in many different directories and on different servers manageable. There's tremendous value in having the capability to select File | Open | Table and browse through the aliases that you set up. In addition, you can use aliases in your code to refer to files. If you move the files, you just need to define the new path in the alias.
Using an alias offers the following benefits:
Long pathnames are shortened to a single user-defined word.
Your applications are instantly relocatable. ObjectPAL code can refer to objects by means of an alias. For example, when the path of your tables changes, redefine the alias to point to the new path.
You can use multiple sets of data with the same application. After an application is set up with an alias, you can redefine your alias to point to a different path; instantly, you are working with a different set of data. This makes it possible to develop an application on your local drive and then switch the tables it uses to network tables and even to a SQL server with little modification.
You can set up aliases on a system by selecting Tools | Alias Manager or by using the BDE Administrator. You can use the Aliases tab of the BDE Administrator to easily browse through existing aliases and set the paths of existing aliases or add a new alias. I find it easier to use the BDE Administrator to add and alter aliases (see Figure 1).
Figure 1: The Databases tab from the BDE Administrator
Public and Project Aliases
You can create either a public or project alias. Project aliases are stored in the PDOXWORK.CFG file, which is loaded whenever you change working directories. You can think of project aliases as aliases that belong to a certain project stored in a specific working directory.
Tip: If you are developing an application using local tables and you know you are eventually going to move the data onto a SQL server, then do yourself a favor and spend a few hours studying the field and table naming rules of your target SQL server before you create your first table. While creating your local tables, use a naming convention that uses common rules. If you use the naming rules in common between the two database types, then you will save yourself time when you move your data to the SQL server because SQL servers often have different naming rules from the naming rules in Paradox.
Where to Put Your Tables
When you're ready to start creating your tables, you need to decide where you want to place them. You have two choices: the current working directory or another directory. Here are my recommendations:
Single-User Application - Power-users and researchers working with data will probably want to just put all files (tables, forms, reports, etc.) in the same folder. A single location contains everything.
Business Database Application - For a business database application (single user or multi-user), I recommend you put all of your tables in a data folder and the main or reusable Paradox files such as forms, queries, and reports in an application folder.
Either way, if you are going to be using your Paradox application (the static reusable files) as well as temporary files (temporary tables, reports, queries, etc.), I recommend you also create a temporary folder for temporary files.
If you're developing a single-user application, it makes sense to put all the files in the same directory if you will never need to move the tables to a network directory. If you are developing what might become a multi-user application, consider separating the tables from the rest of the application and using an alias to refer to the tables. Using an alias gives you the ability to move your tables to a network directory later, if needed. Because Paradox doesn't search for a table, you must develop your application with tables in the current working directory or use an alias. Hard-coding table paths are usually a mistake because it then becomes more difficult to move the tables.
Here are the aliases I might create for a psychology desktop application:
PsychData - Contains all the table files and ONLY table files.
PsychApp - Contains the rest of the Paradox files that are static and reusable (forms, reports, queries, libraries, etc.)
PsychWork - Temporary folder I also use as my working directory and is where I try out new tables, queries, forms, and reports. When something temporary becomes static and reusable, I move it to the PsychApp alias.
For convenience, I would probably use the following filesystem structure at least initially:
If I need to move my data, I just grab the PsychWork folder. If all this turns into a multi-user application, I can then move the \My Documents\PsychWork\Data\ folder onto the network and redefine the alias to point to it.
Tip: Put your tables in a directory different from the one that contains the forms, reports, and libraries. Use an alias to refer to the tables. This makes your application instantly a network-compatible application by making the tables relocatable. When you install the application onsite, you simply have to ask where to put the data and where to put the application. The application can be local or Demo Fileswork. Place the data files where they need to be, and change the alias path. If you eventually want to move your data onto a SQL server, then you will have less code to rewrite.
When you create a standard alias (see Figure 2), you can use one of these driver types:
PARADOX Paradox, for .DB tables
DBASE dBASE and FoxPro, for .DBF tables
ASCIIDRV ASCII text, for .TXT tables
Figure 2: Alias Manager showing a standard alias
The Alias Manager available within Paradox by selecting Tools | Alias Manager only allows you to configure the path attribute of a standard alias. To configure the other settings (for example, for a Paradox driver), you use the BDE Administrator. With a standard Paradox installation, the BDE Administrator is available in your computer's Control.
Advanced Concept: The Paradox Driver Settings
Figure 3 shows the BDE Administrator displaying the Paradox driver settings.
Figure 3: Paradox driver settings in the BDE Administrator
The following table lists the settings of the Paradox driver. For other driver settings, refer to the BDE Administrator help.
Internal version number of the Paradox driver.
Type of server to which this driver helps you connect. Can be SERVER (SQL server) or FILE (standard, file-based server).
The directory location of the Paradox network control file PDOXUSRS.NET. The active NET DIR parameter is stored in the Paradox section of the BDE configuration file and has precedence over any other NET DIR parameters that may be stored in older 16-bit configuration files, or in the System Init section of the current configuration file, or in the Registry. These other NET DIR entries will have no effect. To access a Paradox table on a network drive, the active NET DIR parameter in the Paradox section of the BDE configuration file must point to a network drive and folder in common to all users.
Language driver used to determine table sort order and character set. [available drivers]. US default: 'ascii' ANSI (DBWINUS0)
Type of table format used to create temporary Paradox tables. Level 7 - Paradox for Windows 32-bit tables Level 5 - Paradox 5.0 tables Level 4 - STANDARD table format introduced in Paradox 4.0 Level 3 - Compatible table format used by Paradox 3.5 and earlier versions. Default: Level 7. To use Blob fields, secondary indexes, and strict referential integrity, specify either Paradox level 4 or Paradox level 5 tables. You will probably want to use the lowest level possible in order to maximize backward compatibility. Choose Level 7 only If you need the advanced indexing features supported by that table format. For example, Paradox 7 tables are the only level that completely support long filenames (this is an issue when dealing with RI or lookups across directories). Note: The default level is 7 unless the BDE is already on the system. The setup will leave the settings unchanged if it finds the BDE.
Size of disk blocks used to store Paradox table records, in multiples of 1,024 bytes. Valid settings depend on the table format: Level 5 and 7 - 1,024, 2,048, 4,096, 16,384, and 32,768 Level 3 and 4 - 1,024, 2,048, and 4,096 Default: 2,048
Percentage of current disk block that must be filled before Paradox will allocate another disk block for index files. Can be any integer ranging from 1 to 100. Default: 95 Note: Smaller values offer better performance but increase the size of indexes. Larger values give smaller index files but increase the time needed to create an index.
Specifies whether Paradox tables can be modified using applications that do not support referential integrity (such as, Paradox 4.0). For example, if TRUE you will be unable to change a table with referential integrity using Paradox 4.0; if FALSE, you can change the table, but you risk the integrity of your data. Default: TRUE.
Advanced Concept: SQL Aliases
The database engine provides several SQL native drivers including InterBase, Oracle, Microsoft SQL, Sybase, DB2, and Informix. These native drivers generally offer greater control and speed over many ODBC drivers. When both a native and several ODBC drivers exist for a SQL server (for example, as with Oracle), you might wish to do some experiments with them to determine which will perform best for your application architecture. Figure 4 displays an Oracle SQL alias in the Alias Manager.
Figure 4: Alias Manager showing an Oracle SQL alias
Advanced Concept: ODBC Aliases
You can make use of any ODBC data source when you create an alias (see Figure 5). To create an ODBC alias, first you must use the ODBC Administrator to add, delete, and configure ODBC drivers or data sources. This command appears when you right-click an existing ODBC alias in the Databases tab of the BDE Administrator or the ODBC driver on the Configuration tab. It displays the ODBC administration utility provided by your ODBC driver vendor.
Figure 5: Alias Manager showing an ODBC alias
To make use of an ODBC driver, follow these steps:
Add the ODBC data source to your system using the ODBC Administrator.
Define the DSN (data source name). Note that if AutoODBC in the BDE Administrator (under Configuration | System | Init) is set to TRUE, then any ODBC DSN automatically shows up as an alias in Paradox. The default is set to TRUE when installing Paradox onto a machine that does not have the BDE already installed.
Set up an Alias that uses the data source.
Note: If you add an ODBC data source, you must define its DSN before you can connect to that database.
Most users use public aliases which are stored as part of the settings for the BDE Administrator on your computer. As an alternative, you can use a project alias which is stored with the project and loaded simply by changing your working directory to the folder containing it.
If you use a public alias you must configure it (add it to the BDE) whenever you setup a new user. If you use a project alias, it's in the working directory so it's deployed when you copy all the files to a new user. Is that more clear?
Finally a well written page on aliases, thank you.
After using Paradox for years I lost my Borland PdoxWin-7, and found Corel Pdox-8 most annoying in the way it forces me to change my (poor) filing systems.
Recently my BDE was messed up (by CCleaner probably) , I used 27573_bde_install to get it to work again and in some cases my applications, written with Delphi and XE2, work. But some do not and I need to manage ALIASES easily, not there yet.
Then I would like to transform my .db files in interbase (I must learn interbase too).
How can .db files be transformed into interbase files?