This section contains error messages for Adaptive Server insert commands.
14
Attempt to insert duplicate key row in object '%.*s' with unique index '%.*s'%S_EED
No two rows can have the same index value (including NULL) in a column or columns with a unique index. Adaptive Server checks for duplicate values when the index is created (if data already exists) and checks each time data is added with an insert or update. Error 2601 occurs when you try to put duplicate index values into a column or columns with a unique index.
Using a unique index makes sense only when uniqueness is a characteristic of the data itself. Choose one of the following solutions, depending on whether or not you need a unique index:
If you need duplicate index values in the indexed column or columns, drop the unique index and create a nonunique index instead.
If you need a unique index on data which contains duplicate values, you must change some values to remove the duplicates. To do this:
Use a select statement to find the row which will be duplicated by your update or insert command.
Modify either the data in the table or the data which you want to insert, so that the index values do not match.
Refer to “create index” in the Reference Manual for information about indexes.
All versions
22
Could not find leaf row in nonclustered index '%.*s' page %ld that corresponds to data row from logical data page %ld, row offset %d during update index attempt after data page split in dbid %d.
This error may be due to a hardware problem.
This error occurs when Adaptive Server fails to update a nonclustered index at the leaf level after a page split (a page split occurs when a page fills up and there is no more room to write on that page). This error message indicates index corruption.
This is a very serious error. You may be able to recover from this error but you may have to restore from known, clean backups.
Record the value of the data page and index name (or ID if that is given instead) from the error message. Using this information and the instructions in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter, determine which table corresponds to the data page number from the error message text.
If the table determined in step 1 is a system table (object ID is less than 100) and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index. Then go to step 5.
If the table determined is step 1 is a system table and the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption, but it may be necessary to restore from clean backups.
If the table determined in step 1 is not a system table and the message displayed the index ID rather than the index name, find the name of the index involved by executing the following query:
1> select name from sysindexes 2> where indid = index_ID 3> and id = object_ID 4> go
where object_ID is the ID of the table as determined in step 1 and index_ID is the ID of the index specified in the error message.
Drop and re-create the index using the table name obtained in step 1 and the index name determined in step 3.
To verify that all problems have been resolved on this table, run dbcc checktable and dbcc tablealloc on the affected table.
If problems persist, this procedure may not be sufficient to clean up the index corruption, and you should contact Sybase Technical Support. Have the output from the dbcc checkalloc or dbcc tablealloc and dbcc checktable commands available for review.
All versions
14
Attempt to insert duplicate row in table '%.*s' with index '%.*s' in database '%.*s'. Could drop and recreate index with ignore duprow or allow duprow.
Tables with clustered indexes do not allow duplicate rows. Error 2615 occurs when you try to insert a duplicate row in a table which already has a clustered index.
If the duplicate values are a result of incorrect data, change the data and rerun the transaction.
Otherwise, decide whether you want to allow or prevent duplicate rows in the table where the clustered index will be created. Use one of the following procedures.
ignore_dup_row and allow_dup_row are
mutually exclusive options of the create index command.
Do not use them together in the same statement, or you will cause
Error 1916.
Create the index with the allow_dup_row option:
1> create clustered index index_name on table_name 2> with allow_dup_row 3> go
Subsequent update and insert commands can create duplicate rows after the allow_dup_row option is set.
Do not use this procedure if you have a unique index on any column or columns in the table. Unique indexes are only used on tables where no duplicate rows exist.
Create the index with the ignore_dup_row option:
1> create clustered index index_name on table_name 2> with ignore_dup_row 3> go
Existing duplicate rows will be deleted from the table as the index is created. Subsequent attempts to enter a duplicate row with insert or update are ignored and the insert or update is cancelled with an informational message. If the insert or update is part of a larger transaction, the rest of the transaction will continue as usual.
Refer to “create index” in the Reference Manual for information about ignore_dup_row and allow_dup_row.
All versions
20
Keys did not match overflow page when inserting row at end of page (%S_PAGE) that has overflow page (%S_PAGE) that is not disconnected in dbid = %d.
With a clustered index, Adaptive Server maintains data so that the physical order of rows is the same as their logical, indexed order. The bottom or leaf level of a clustered index contains the table's actual data pages. When an index key has a large number of duplicates, not all of these may fit on the same data page. Adaptive Server then allocates a new data page, marking it an “overflow page” to store the additional values. The original page and the overflow page now both contain at least one row with that key value.
If the data corresponding to the key value on the first page is now updated or deleted so that the key no longer appears on that page, Adaptive Server removes the association between the two pages. The overflow page is now a regular page just like any other data page.
Error 2619 is raised when Adaptive Server attempts to insert a key value at the end of a page, and the key currently in place has an associated overflow page, but the key does not match the key value in the overflow page. It is likely that the page served as an overflow page at some point, but when a row with that key value on the first page was updated or deleted, the overflow page was not marked as a regular (disconnected) page.
When Error 2619 occurs, your connection to Adaptive Server is broken. It is a serious error as it indicates that you have a corrupt clustered index on the table. However, there is a straightforward solution as discussed under “Action” below.
Use the following steps to resolve the error:
Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter to identify the table.
Use sp_helpindex to list all indexes associated with the table. Identify the clustered index on the table.
Drop and re-create the clustered index.
Run dbcc tablealloc on the table to ensure that the problem is resolved. If errors are reported, contact Sybase Technical Support for assistance.
When calling Technical support, have the following information available:
Server version and SWR Rollup level
Server error log
Text of all error messages
All versions
21
The offset of the row number at offset %d does not match the entry in the offset table of the following page: %S_PAGE.
An offset table is stored at the end of every data page and it stores where rows are located on that page. Adaptive Server uses the offset table to quickly access the rows in each page. Error 2620 occurs during an insert operation when Adaptive Server detects inconsistencies in the offset table of the page specified by the error message.
This error may be due to a hardware problem.
This is a serious error. You may be able to recover from this error but you may have to restore from known, clean backups.
Record the value of the page from the error message. Using this information and the instructions in “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter, determine which table and index corresponds to the page number.
If the object encountering the error is not a system table (a system table's object ID is less than 100), continue with step 3.
If the object is a system table and the index ID is not 0, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the system table index.
If the index ID is 0, contact Sybase Technical Support. They may be able to help you repair the corruption but it may be necessary to restore from clean backups.
For user tables, if the index ID is 0 or 255, continue with step 4.
If the index ID is not 0 or 255, translate it into an index name:
1> use database_name 2> go
1> select name from sysindexes 2> where id = object_ID and indid = index_ID 3> go
To ensure that the information needed to re-create the index is available, run sp_helpindex on the index prior to dropping it.
Drop the index.
Re-create the index. This clears the corruption in most cases.
Run dbcc checktable on the table to verify that the corruption is gone.
If the index ID is 0 or 255, do one of the following:
Restore the database from clean backups.
Refer to “How to Rescue Data from a Corrupted Table” in the Encyclopedia of Tasks chapter.
WARNING! Some data on this page might be lost if you recover your table using bcp or select into (that is, the corrupted row and rows following it might be truncated and contain the wrong keys). Compare the two tables (old and new) row by row (by joining them on a primary key, for example) to determine which rows are different (corrupted).
Before dumping your database, make sure it is working correctly. More specifically, the following commands should be run prior to each dump:
dbcc checkdb.
dbcc checkalloc or dbcc checkalloc with the fix option. (Refer to “How to Fix and Prevent Allocation Errors” in the Encyclopedia of Tasks chapter for information about running these commands in multi-user mode and how to prevent spurious allocation errors from dbcc commands.)
If problems persist, this procedure may not be sufficient to clean up the index corruption, and you should contact Sybase Technical Support with the following information:
Server release and SWR rollup level
Server error log
Text of all error messages
Output from dbcc checkalloc or dbcc tablealloc and dbcc checkdb
All versions
22
Illegal attempt to insert duplicate key row in the clustered index for object ’%.*s’ in database ’%.*s’.
Error 2626 is raised when you attempt to insert a row into a table with a clustered index, and the key value being inserted matches an existing index key value, which was not expected.
Error 2626 can be caused by:
a corrupt clustered index.
an Adaptive Server problem.
Corrective action depends on the type of table, and whether the table is partitioned. If the problem persists after applying the correction, call Sybase Technical Support.
Unpartition the table:
1> alter table <table_name> unpartition 2> go
where <table_name> is the object named in the message text.
Repartition the table:
1> alter table <table_name> partition <number_of_partitions> 2> go
If the object encountering the error is a system table, refer to “How to Fix a Corrupted Index on System Tables” in the Encyclopedia of Tasks chapter for instructions on how to repair the index. Then go to step 5.
If the object encountering the error is a user table, identify the clustered index on the table:
1> sp_helpindex <table_name> 2> go
where <table_name> is the object named in the message text.
To ensure that the information needed to re-create the index is available, run sp_helpindex on the index prior to dropping it.
Drop the index.
Re-create the index, or create a non-clustered index. This eliminates the 2626 error in most cases.
Run dbcc checktable on the table to verify that the corruption is gone.
All versions
21
In database '%.*s', page %ld is linked forward to page %ld, but that page is linked backward to page %ld. Please report this internal error to Sybase Technical Support.
This error may be caused by a hardware problem.
When updating a table or index, Adaptive Server may determine that there is not enough room on a page to insert additional data. A new page is then allocated for the object. Existing rows may be moved to this page and new rows inserted. Error 2628 is raised when Adaptive Server fetches a page by following the forward pointers, examines the existing page linkage, and finds that the backward pointer does not point to the previous page as expected. Since the linkage problem could be worsened by continuing the page split, the operation is aborted.
When dbcc detects this problem, it raises Error 2503 (Table Corrupt: Page linkage is not consistent; check the following pages: (current page#=%ld; page# pointing to this page=%ld; previous page# indicated in this page=%ld)).
Error 2628 is due to corruption of page pointers for the object. Use the following steps to resolve the error:
Identify the object using one of the pages identified in the message. Refer to “How to Find an Object Name from a Page Number” in the Encyclopedia of Tasks chapter for information.
If the page is a data page (index ID = 0), drop and recreate the clustered index on the table.
If this is an index page (index ID is greater than 0), drop and recreate the index.
Run dbcc pglinkage on the table to verify that the problem is corrected. Be sure to check both next page and previous page pointers.
All versions
