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.
Virtually hashed tables must have unique rows. Virtually hashed tables do not allow multiple rows with the same key column values because Adaptive Server cannot keep one row in the hash region and another with the same key column value in the overflow clustered region.
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.
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.
Are partitioned.
Use frequent table scans.
Have more data rows in the overflow region than in the hash region. In this situation use a B-tree instead of a virtually hashed table.
