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 


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


Building Tables
Part 3: Table Language, Table Level and Passwords
By: Liz Woodhouse
ParadoxCommunity.com

Introduction

In the previous section, we discussed using validity checks and table lookup to help ensure data integrity, simplify development and avoid unnecessary coding.

In this article, we'll continue exploring the table structure dialog, and discuss the following items:
  • Table Language
  • Table Level
  • Passwords


Table Language

Table language determines what characters can be stored in the table. I won't attempt to list the table languages available or the characters they support as they are too numerous. Instead, please check in the table structure/restructure dialog in your version of Paradox to see which languages are available. However, it is important to note a few important facts related to table language.

Borland Database Engine (BDE) Version
Table language may be impacted not only by the version of Paradox you are using, but also by the version of the BDE (or IDAPI) you are using and by the table level in use. If you are using "international" table languages (all except Paradox 'ascii' and 'ascii' ANSI), you should use BDE 4.51 or earlier, or at least test the version of the BDE you intend to use to ensure query performance is adequate for your needs (it has been reported and documented that queries (both QBE and SQL) against tables using international language drivers are noticeably slower than those against the two table languages mentioned).

BDE versions can be obtained here.

Using non-Latin Alphabets
When using a table language which supports character other than standard 'ASCII' characters (e.g. the Russian, Greek or Hebrew alphabets), it may be necessary to perform the following steps before you can enter, display or print those characters:
  • You must enable support for the characters of interest in Windows. This is done by either using a version of Windows which supports the characters natively, or by adding language support in Control Panel. The later is generally done in the Keyboard applet in Control Panel, but depending on your version of Windows, the procedure may be different.
  • When using a computer on which more than one keyboard language is supported, be sure you've switched to the correct keyboard language prior to entering data in the Paradox table.
  • You must set all field objects (in tables, forms and reports) to use a font script which supports these characters. This is done in Paradox as a font properties option (details on setting font properties will vary between versions, please consult the help file for your version).
When And Where To Assign Table Language
In the BDE, there is a default table language setting for Paradox tables. This table language is used by default when creating new Paradox tables. You may select a different table language when creating a new table. While it is possible to change table language on an existing table in the restructure dialog, this should be avoided if the table has data (unless you are absolutely certain you know the impact of the change). This is because existing data in the table will not be converted to the new table language. Therefore, for example, a character which used to look like the letter õ may switch to not being displayed at all or being displayed as a box character.

To convert a table with data from one table language to another, follow these steps:
  • Create a new table with the same structure as the one with the data, but with the new table language. You can use the "Borrow" button in the create table dialog to borrow structure information from another table.
  • Add the data from the old table to the new table.
  • Once you are sure the data has been successfully transferred, move the old table to a backup directory and rename the new table to the old table's name.
Using Different Table Languages
Tables which are going to be joined in some fashion (referential integrity, table lookup, or in a data model) or which will have their data compared via code or query should use the same table language. If they use different table languages, it's possible links will be broken, comparisons will yield unexpected results or data which should automatically be transferred from one table to another (such as in table lookup) will not be compatible and therefore will not transfer.


Table Level

Contrary to common assumption, table level is not the same as Paradox version. Rather the table level is numbered the same as the first version of Paradox to support that table level. Thus, level 5 tables were introduced with Paradox 5. Any version of Paradox can use tables with levels the same or less than the Paradox version number.

The BDE holds the setting for the default Paradox table level to use. You may also select a level when creating a Paradox table, but when saving a table, Paradox will generally use the lowest table level which supports the field types and other features specified.

Valid table levels for Windows version of Paradox are 3.5, 4, 5 and 7. (Occasionally, level 7 is displayed with additional versions after it "7 & 8" or "7, 8 & 9", however, the level is 7.) Level 3.5 (referred to in the BDE as 3) is offered for compatibility with Paradox 3.5 and earlier and should not be used unless you need this compatibility. Level 4 is the default table level in the BDE and is also compatible with Paradox 4.0 for DOS. Level 4 and 5 tables support BLOB field types, secondary indices and strict referential integrity. Level 7 is the highest table level and supports unique and descending secondary indices, as well as long file names.

Notes on Table Level
The only difference in table levels is what features they support. Linked tables do not have to be of the same level.

A table's level should not be changed using the table repair utility. The field in this utility which allows one to specify table level is meant either to display the level of the table being repaired or to allow the user to specify the level for a table which is so damaged that the utility cannot correctly tell what level it is. To change a table's level, restructure the table and use a field type or other feature (see above) which is only supported by the desired level. You can then go back and delete or remove the feature used to change the table level (while the level can be automatically raised, Paradox does not automatically lower it when the higher level features are removed).

If when restructuring a table, you try to save the structure and get an error stating that a higher table level is required, cancel the restructure or undo your changes, then add a descending secondary index to the table and save it. This will automatically change the table level to 7. You can then return to the restructure dialog, remove the index (if desired) and then make the other desired changes. For some unknown reason, some features (such as descending secondary indices) will automatically change the table level while others will not.


Passwords

While Paradox table passwords cannot secure your tables against a determined hacker, they can be an effective way to prevent accidental edits, and when combined with server security, a properly coded interface and Paradox Runtime, they can provide a fair level of security for your data. We won't review all the details of what levels of protection passwords offer, for that please review the help file which comes with your version of Paradox. For our purposes here, we'll review passwords in general and suggest some methods of working with them.

Password Types and Rights
There are two types of Passwords in Paradox: Master and Auxiliary. The master password gives complete rights to a table (empty, delete, restructure, copy, etc.). Auxiliary passwords give varied rights, and there can be more than one auxiliary password per table (please see help for exactly how many). Auxiliary passwords allow you to specify both table and field rights (though the field rights are limited by the table rights). This allows you to set passwords which allow users to only insert and edit records, only see some of the fields in a table, only read the table, etc. (Please see the help file for exact details on assigning passwords and rights.)

Suggestions for Using Table Passwords
Take advantage of passwords. They can be an easy way to ensure data is seen and modified only by those with the proper rights.

Don't tell users the password(s). Or, if you must let them access tables directly (which I do not recommend), only give them auxiliary passwords, not the master password. If users know the actual table passwords, then they can access the tables directly, and you will have no control over what kinds of edits are made at the table level. Also, if users know the actual passwords, then when one leaves the company, you'll need to restructure all your tables and change the passwords and see that they're redistributed to the proper users. In other words, it's a maintenance nightmare as well as a security risk.

Instead of giving users the actual table passwords, I recommend you establish a login routine for your application, issue user names and passwords which are user specific, grant users rights and then use code to issue the actual passwords (according to user rights and assuming the user properly logged in). There's at least one third party tool available which does this. If you'd like more information, check out RDA's Security Guard.

NOTE: If you decide to code this yourself, do not quote passwords in code. E.g. do not use addPassword("LizPassword"). This is because quoted strings can be viewed by opening the form in any text editor. Instead, use chr() or a combination of various string-type methods to 'hide' your password.

NOTE2: The table repair utility will require the table's master password to run. It will run whether you type the password correctly or not. This means that it could decrypt and re-encrypt the data with the wrong password, thus leaving you with what can only be described as gobbledegook. Also, the table repair utility removes all auxiliary passwords, so remember to add them back after using this utility. For a utility which will not proceed without the proper master password and which will not remove auxiliary passwords, check out ChimneySweep by Sundial Services.


Summary

While these advanced Paradox table settings can often be left at their defaults, knowing about them can help you take full advantage of everything the Paradox table structure has to offer.


Part 4: Primary and Secondary Indices


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.