These are the limitations for virtually-hashed tables:
truncate table is not supported. Use delete from table table_name instead.
SQL92 does not allow two unique constraints on a relation to have the same key columns, so Adaptive Server does not support primary key or unique key constraint on the same key columns as the key columns of the virtually hashed table.
Because you cannot create a virtually-hashed clustered index after you create a table, You also cannot drop a virtually-hashed clustered index.
You must create a virtually-hashed table on an exclusive segment. You cannot share disk devices you assign to the segments for creating a virtually-hashed table with other segments. In other words, you must create a special device first, and then create an exclusive segment on the device.
You cannot create two virtually-hashed tables on the same exclusive segment. Adaptive Server supports 32 different segments per database. Three segments are reserved for the default, system and log segments, so the maximum number of virtually-hashed tables per database is 29.
You cannot use the alter table or drop clustered index commands on virtually-hashed tables.
Virtually-hashed tables must use all-pages locking (APL).
The key columns and hash factors of a virtually-hashed table must use the int datatype.
You cannot include text or image columns in virtually-hashed tables, or columns with datatypes based on the text or image datatypes.
You cannot create a partitioned virtually-hashed table.
Do not create virtually-hashed tables that:
Have frequent inserts and updates
Is a partitioned table.
Use frequent table scans
Have more data rows in the overflow region than data rows in the hash region. Using a B-tree is better than a virtually hashed table in this situation.
