|
|
|
|
|
Displays the name that will be used to refer to the table in all scripts in the application. To make the name easier to use in scripts, you can use underscores ( _ ) between parts of the name instead of spaces.
Displays the name that appears when the name of the table is displayed on the screen in an application. This name is usually the same as the table name, but typically has spaces between parts of the name, rather than underscores.
Displays the name under which the table is stored by the operating system or database. By default, this name can be up to eight characters long and must conform to the operating system standards for the system running Dexterity. The appropriate extension, if required, is added automatically.
If you're defining a temporary table, enter "temp" as the physical name.
If you're developing an application for an operating system that supports long file names, you can mark the Allow Long Physical Names option in the Options window. Marking this option allows you to enter table physical names up to 24 characters long.
Determines the series in which this table will be placed. The table series allows you to group related tables in a Dexterity application together using series categories like Sales, Financial and System. You will use these series groupings when you use the Report Writer, set up pathnames, and perform table maintenance routines.
If you're creating Dexterity applications that integrate with Microsoft Dynamics GP, be sure you select the series your application is integrating with. This will allow security and pathname support to function properly in your application.
Specifies the database manager that will be used to create and access the table. Currently, Dexterity: supports c-tree Plus, Pervasive.SQL (P.SQL) and Microsoft SQL Server database types. Memory-based tables, which act like c-tree tables, are also-supported. Use the following guidelines when selecting a database type:
Choose c-tree to use the c-tree Plus database type. Support for this database type is built into Dexterity. No additional components are required.
If you use the c-tree Plus database type, each table will have two files created. One will have the physical name you specified plus the extension .DAT (data file), while the other will have the physical name plus the extension .IDX (index file).
Choose P.SQL to use the Pervasive.SQL database type. (In earlier versions of Dexterity, this database type was know as Btrieve.) Depending upon how you set up your application, your data files can be stored locally or on a server running Pervasive.SQL.
If you use the P.SQL database type, each table will be created with the physical name you specified, plus the extension .BTR. You can use the BtrieveFileNameExtension defaults file setting to specify a different extension.
Choose SQL to use the SQL database type. If you use the SQL database type, each table will be created with the physical name you specified.
Choose Memory to have the table created and stored in the current user’s Temp folder. Refer to Memory-based tables for details about memory-based tables.
Choose Default to allow the database type to be determined at runtime. At runtime, Dexterity or the runtime engine will ascertain which database type to use based upon several system settings. The DatabaseType defaults file setting or the Table_SetDBType() function can be used on any platform to set the default database type.
A command line option can also be used to specify the default database type. The following table lists the command line options and the default database they specify.
![[spacer]](1p.gif){kind=small}
|
Command line option |
Default database type |
|---|---|
|
/Ctree |
c-tree Plus |
|
/Btrieve |
Pervasive.SQL |
|
/SQL |
SQL |
The command line option overrides the DatabaseType defaults file setting. The Table_SetDBType() function overrides both the command line option and the defaults file setting.
Displays the list of fields in the dictionary. Before defining a table, you should have already used the Field Definition window to create the global fields that will be used for the table. To add global fields to the table, simply select the global field in the Global Fields list and click Insert; the field will be added to the table definition after the item currently selected in the Table Fields list. If no field is selected in the Table Fields list, the global field will be inserted at the top of the list.
Displays the fields currently in this table. There is only one significant consideration when inserting fields into a table definition. For optimal performance, it is desirable to group string fields next to each other in the table definition. This is particularly true for string fields that will be used in keys for the table. Through a process called segment combining, Dexterity treats adjacent string fields as a single item, allowing it to perform some table operations more efficiently.
The position of the fields in the Table Fields list is significant. Data in the table is stored according to the position of the fields in the Table Fields list. If you insert additional table fields or change the position of the fields, any existing data will need to be converted in order to be accessed properly.
Displays the size of each record in the data table, in bytes. A record is made up of two parts: a fixed-length part and a variable-length part.
The fixed-length portion of the record stores all fields with fixed lengths. For Pervasive.SQL tables, the fixed-length portion can be up to 4,088 bytes (approx. 4K). For c-tree tables, it can be up to 32,767 bytes (32K). For SQL tables, the fixed-length portion can be up to 8.060 bytes. In all cases you should try to keep the fixed-length portion as small as possible for maximum performance.
The variable-length portion of the record stores all variable-length fields such as pictures and big text fields. These fields share 32K of variable space. For example, if a table stored a 10K picture and a big text field, the text field could store up to 22K of text for a total of 32K.
The record size of the fixed-length portion of the record is calculated automatically as fields are added or removed; the total record size equals the combined storage size of all the fixed-length fields that have been inserted into the table.
Indicates whether the contents of the field will be encrypted in the table, making it impossible to view the contents of this field by accessing the data table from outside the application. An asterisk will appear next to each encrypted field. Encryption can be used for fields such as password fields to prevent users from reading the passwords by viewing the table data with a file viewing utility.
|
Don't change this setting if data for this field has already been stored in the table. Changing the encryption setting may render existing data unreadable. |
Displays a list of the keys that have been created for this table. A key is a field or combination of fields within a table that is used to sort and locate specific records in the table. Typically, the value of the key field or fields is unique for each record in a table so a particular record can be located. Dexterity allows you to create multiple keys for each table, with multiple segments in each key.
Keys appear in the order they were created, and script commands in Dexterity can refer to the keys in scripts by either their name or their numeric position in this list. The selected key will be opened or deleted when either the Open or Delete buttons are clicked. Clicking New opens the Key Definition window, were you can define a new key.
This group allows you to set the following table options:
Mark this option to allow active locking for this table. If you don't mark this option, any change or edit table statements that reference this table and include the lock keyword will produce errors when you attempt to compile them.
|
We strongly recommend that you avoid using active locking in your application. Application performance can degrade when active locking is used, especially when your application uses a SQL database. |
Virtually all Dexterity applications use a four-byte header at the beginning of each table. However, Great Plains Accounting files do not. This option should always be marked, unless you are creating a product that integrates with Great Plains Accounting files.
Mark this option if you want to create a restriction that is always applied to the table. In virtually all cases, you should NOT mark this option. If you're creating a product that integrates with Great Plains Accounting files, and the file you're integrating with uses variant records, mark this option. Before you mark this option, create the table definition and save it, then reopen it. Then mark the Use Restriction option; the Default Restriction window will appear, allowing you to create a default restriction for the table. To remove a default restriction, unmark this option. A message will appear asking if you want to remove the default restriction. Click Yes to remove the restriction.
This feature is used internally by Microsoft.
This option applies only when the SQL database type is used. When this option is marked, an additional field named DEX_ROW_TS is added to the table definition in the SQL database. This additional column stores the UTC date and time the record was created or updated. The value of the field is updated any time the row is updated, whether by a Dexterity-based application or another application.