Paradox Community
Search:

 Welcome |  What is Paradox |  Paradox Folk |  Paradox Solutions |
 Interactive Paradox |  Paradox Programming |  Internet/Intranet Development |
 Support Options |  Classified Ads |  Wish List |  Submissions 


Paradox Programming Articles  |  Beyond Help Articles  |  Tips & Tricks Articles  


Managing Aliases - BDE™ or tcursor?
by Tony McGuire

Common wisdom, and the manuals/online help, say that managing aliases in Paradox® is the job of the BDE Configuration Tool. In most cases, I agree with this. A single desktop or network scenario where it is fairly easy to manage aliases makes the BDE config tool the most logical way to go.

But the config tool isn't right for every situation.

While you can use the config tool over a LAN or WAN, it may be cludgy to do so. And to apply any changes you make with the config tool, "All BDE applications must be restarted." (Even though in the case of changing aliases you don't get this warning, changes made to aliases in the BDE don't immediately take effect in a copy of Paradox already running. You must still exit and restart.)

What about remote management, where you have 20 offices, each with its own server, with 5+ workstations in each office? Do you reconfigure your copy of Paradox, open the remote CFG on each workstation, make changes and save; then tell each office that the copy of Paradox on each workstation needs to be shut down and restarted? Or do you run a common CFG from the server in each office, modify it and still have to have each workstation copy of Paradox restarted. That's if your desktop can even see each workstation or server. These scenarios could take a full day or longer. Or do you drive around to each office and make the changes to each workstation and/or each server? That could take a full week!

There is a better way! It won't apply to every situation, but it can save hours or days when applied in those scenarios where it works better than standard practices.

Paradox allows you to create aliases on-the-fly. Either 'standard' aliases or 'project' aliases.

From the on-line Help
Syntax
1. addAlias ( const aliasName String, const type String, const path String ) Logical
2. addAlias ( const aliasName String,
              const type String,
              const params DynArray[ ] String ) Logical
3. addAlias ( const aliasName String, const existingAlias String ) Logical
Description

addAlias adds public alias a to a session. To add a project alias, use addProjectAlias.

In Syntax 1, specify the alias name in aliasName, its (Standard) in type, and its full DOS path in path.

In Syntax 2, specify the alias name in aliasName, the SQL alias type (Interbase, Oracle, Sybase, or Informix) in type, and the parameters in params.

Syntax 3 copies an alias from existingAlias to aliasName.

An alias added using addAlias is known only to the session for which it is defined, and exists only until the session is closed. Use saveCFG to save public aliases in a file. By default, public aliases are stored in IDAPI.CFG. They are available from any working directory and visible to any application that uses Borland Database Engine (BDE).
What this doesn't say is, even if an alias already exists, using addAlias again, using the same alias name, just replaces the alias path you are 'adding' with the path you pass it. The new path takes effect immediately; you do not have to shut down and restart the app (in fact, unless you use saveCFG, this would cause your new alias path to be deleted).

Thus, you can 'store' aliases in the CFG file using the BDE or saveCFG, and modify them at runtime. Then you can discard the changes when the session is closed (exiting Paradox) or save them using saveCFG. If using an IDAPI.CFG that is common to multiple workstations, however, the new/modified alias wouldn't take effect on other workstations until those workstations' copies of Paradox were exited and restarted.

Now let's take a look at using a table for managing aliases. This will be for a LAN system, with 10 workstations and a server. The server contains a table, "AliasDefs.db". This table contains 4 fields (you may wish to add some, based on your own scenario):

AliasName, AliasPath, WorkGroup, SaveLocal

It is keyed on AliasName, with a secondary index - "GroupName" - keyed on the "WorkGroup" field, Ascending, and "SaveLocal", Descending. SaveLocal has one of two values "0" or "1". More on this later.

The first two are obvious. WorkGroup can be a field whereby you can define which workstations should apply these aliases. The last, SaveLocal, will be a flag that tells the workstation copy of Paradox whether to do a saveCFG for the alias, saving the BDE settings in its local copy of IDAPI.CFG. This might be critical if the workstation's connection to the server is down; the last known paths in that workstation's IDAPI.CFG could still then be used. If you have a setup routine in your app, which modifies directories/files on-the-fly, you could have a scenario where you place files for updating on the server, the workstations apply the changes and modify/add aliases/paths to their local CFG; if the new aliases weren't saved, your app couldn't work.

In this scenario, there is no 'common' IDAPI.CFG on the server. On startup, your app opens a tcursor on "AliasDefs.db", which is on the server, using "GroupName" as the opening index.

It performs a setRange() on the table, using its workgroup (which you define and control with your app) as the only value. Instantly, only aliases for that workstation's group are available to the tcursor. The secondary index you opened the table on causes the records with a "1" as a value for "SaveLocal" to appear first (1=Yes, save local, 0=No, don't save). If you perform two scans on the tcursor (or apply two different setRanges() with additional parameters), looking first for records with 1, you can use saveCFG between the two scans (if any records containing a "1" value are found). Then the aliases that shouldn't be saved won't be.

Within your application, you could periodically check the table containing alias names and definitions - and reset them on-the-fly. This is particularly useful when using scripts and library methods that use aliases during their operation. Data models are touchy midstream; I haven't tried adjusting them in the middle of work. Although, you could test for alias changes immediately before open a particular form, apply changes, then open the form.

Changes made through use of the tcursor/table methodology can take place on-the-fly. Changes made through the BDE can not.
This enhancement to using the BDE configuration is very useful when you are managing multiple remote systems. A tcursor can often be applied to administer the "AliasDefs.db" where making changes to the remote config files is difficult at best.


This methodology is not necessarily the best for every situation. But having it as an option is one more thing that makes Paradox shine. As developers using Paradox, we have far better control over the environment our applications are written in than we even realize. It's left up to us to decide how, and when, to apply the Power of Paradox.


Discussion of this article


 Feedback |  Paradox Day |  Who Uses Paradox |  I Use Paradox |  Downloads 


 The information provided on this Web site is not in any way sponsored or endorsed by Corel Corporation.
 Paradox is a registered trademark of Corel Corporation.


 Modified: 15 May 2003
 Terms of Use / Legal Disclaimer


 Copyright © 2001- 2003 Paradox Community. All rights reserved. 
 Company and product names are trademarks or registered trademarks of their respective companies. 
 Authors hold the copyrights to their own works. Please contact the author of any article for details.