In many cases, Iron Speed Designer cannot create certain pages that require primary keys, such as Edit Record and Show Record pages.  This occurs because the associated database tables and views used in your application do not have primary keys.  This also applies to queries created in Iron Speed Designer which do not have designated primary keys.

For database tables, database views and queries that do not have explicitly defined primary keys, you can specify ‘virtual’ primary key relationships in Iron Speed Designer, allowing you to create Edit Record and Show Record pages (and others) for these tables.  You don’t have to change your database schema in order to build full-featured applications.

Benefits

Virtual primary keys provide all of the benefits of a real primary key (explicitly declared within the database) to a database table or database view:

• Physical tables:  Virtual primary keys allow you to create Edit Record, Show Record, Table Report and Edit Table pages.

• Database views: Virtual primary keys allow you to create Show Record and Table Report pages and, in many cases Edit Record pages.

Virtual primary keys have several additional benefits:

• Images in tables with virtual primary keys can be displayed, since binary database images can only be displayed for tables with primary keys.  This overcomes a limitation resulting from technical issues involving HTML/HTTP capabilities.

• Improving the accuracy of the table's default keys (implicit IDs) and decreasing the size of each record's default key for many tables and views.  This improves the run-time performance of Table Report pages and decreases the size of the ViewState for such pages.

Caveats

Make sure that a virtual primary key you are adding to the table or view is indeed unique. The rule of thumb is to use combination of the primary keys from the underlying tables to compose a virtual primary key for a view. Note, that often it is not possible to select a virtual primary key for a view because there is no combination of fields that is unique. For example, consider a view that has just one field – First Name – from the Customers table. This field is not unique and can not be selected as a virtual primary key.

Virtual primary keys cannot be added to physical tables that already have a physical primary key.  Tables cannot have multiple primary keys, either physical or virtual.

To create a composite virtual primary key, check the “Virtual primary key” box for each field in the composite primary key.