Contents of Table (cont)

<< Page 1

Table Properties

The table properties are spread across a number of options, all found on the Document menu (don't be confused by the name; some of these options wil be applied to table and therefore across the application).

Document Properties
  • User Help
  • Preserve old current date, etc, on Modify
  • Transferable table which indicates that the table is now owned by Windows and not DOS.

This should only be significant if DOS has been involved in the app, but the option appears under all circumstances.

No other settings on this dialog relate to the table. The defines table option is a property of the form; a table does not need a form in order to exist.

Document Security

The security settings for the table set the base line for all documents and procedures that use the table. Thus if you change the View Records setting from its default of Low3 to Medium3, all forms built over this table will have a minimum view of Medium3. Those forms will only be able to set higher security values.

You can only set the data encryption option at the table level (obviously).


The performance option lets you change the physical order of records in the table. These details are stored at the table level.

(You can also use the cluster by extension with the reorganize DQL command, which also allows reverse sorting if needed, an option not available with the via performance dialog.)

Everything else on a form, table-defining or otherwise, belongs to that one and only form.

What Is A DataEase Table?

DE tables are not the same as SQL base tables, or tables as Access thinks of them. This is because a table can contain virtual fields.

Virtuals are the topic of another article, but for the moment, just think of your fields in your table as being either real or virtual. Real ones will have actual data stored on disk and can be indexed. Virtual ones are derived at runtime, take up no physical presence and cant be indexed. However, they can be seen application as well as table wide, allowing you to use them in field derivations, DQLs, relationships, and forms.

If a DfW table is compared to NetPlus, it actually combines two layers: the backend or SQL layer, and the entity layer, which provides an application-wide view of that table. If a DfW table were built over a SQL table2, you would be allowed some limited amount of setting to control the type of data that could be entered in a field, and add virtuals.

In a sense, you can think of NetPlus as allowing a three-tier view1, Application Wide Layer, Specific form), native DfW as having two tiers (the DfW table, which is a kind of cominbation of the SQL Table/Application layers, and the specific form), and DOS as really being single tier3, where data storage and presentation are rolled into a single object.


1. Re Prevent-entry: the name gives it away! It's a form/user interface setting, not a table one! There is no SQL equivalent to this, for example.

Once upon a time, we used to in DOS wrap up prevent-entry and virtual into the same field setting, as though they are slightly different shadings of the same thing.

Really, we should be able to override this at the form level, but unfortunately we can't. So I often will have two sets of fields, mirroring allow-entry fields with virtuals so that I can choose which to put on a form.

2. Re Sql Views: It is possible indeed, recommended for use SQL views rather than base tables, and like a DfW table, a SQL view can contain data that isnt there. Generally, though, this will be transparent to all DataEase products, which will simply see a set of columns.

3: Re DOS Views: This is true of 4.53. DOS 5.x introduced some separation of form from table, but in my opinion it had too many disadvantages to be of great use. I never liked the way you had to include required fields in the view. Yes, of course, one cannot enter data if required values are missing, but I will frequently use a DfW form to simply update certain details of existing records.