![]() |
![]() |
|
![]() |
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 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:
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:
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. ![]() |
![]() |
|