Login | Sign Up
ErrorKey - Search engine for Error codes and messages     
  SQL Server:SQL Server System Error Messages  [ 1000 result(s) ]
IBM IBM DB2 MICROSOFT SYBASE SQL Server 
 3203 Severity Level 16  -  Release 10.0 and Later Backup Server has detected a SQL Server error. Release 4.9.x and Earlier Read on dump device '%.*s' failed, vsn=%ld return=%d status=%ld. Please consult the SQL Server er SYBASE SQL Server
For SQL Server release 10.0 and later, Error 3203 is displayed when a problem occurs with a remote procedure call to the Backup Server. In this case, the error is on the SQL Server side. For SQL Server releases previous to 10.0, this message is displayed when an error occurs when doing a load from a SQL Server dump. The error message output includes: • vsn – the virtual socket number. • return – the return value: 0 means successful; -2 means failure. • status – the ending status, displayed in decimal value. The most common value is 524288 which usually means an I/O error. Some causes are: • Write protect is turned on (it must be off when loading a tape because the device is opened read/write). • No dump exists on the media being accessed (for example, a blank tape or the wrong device specified). • The media that contains the dump is not readable.
Release 10.0 and Later • Check the SQL Server and Backup Server error logs to determine the cause of the error being sent from the SQL Server. • Test the connection between the Backup Server and the SQL Server by logging into the SQL Server through isql and typing: 1> execute backupserver...sp_ps 2> go where backupserver is the name of your Backup Server. This executes sp_ps on the Backup Server. Release 4.9.x and Earlier • Make sure write protect is turned off (it must be off when loading a tape because the device is opened read/write). • At the operating system level, check the contents of the tape. Additional Information If you need to call Technical Support, have the following information on hand: • SQL Server version and EBF Rollup level • Backup Server version • SQL Server and Backup Server error logs • Text of all error messages • Operating system error log
Comments
 
 926 Severity Level 14  -  Release 10.0 and Later Database '%.*s' cannot be opened. An earlier attempt at recovery marked it 'suspect'. Check the SQL Server errorlog for information as to the cause. Release 4.9.x and Ear SYBASE SQL Server
This error occurs when you attempt to reference a database that has been marked suspect in one of the following circumstances: • During start-up of SQL Server • By the System Administrator as a result of certain critical errors This is a serious error and must be corrected if you want to access your database again. This error may be caused by hardware failure.
Since the 926 error is the result of an earlier error or action, the recommended action is to determine what caused the database to be marked suspect. In order to determine the cause, check the SQL Server error log for error messages for the database in question and try to eliminate those first by using the troubleshooting procedures in this manual. Depending on why the database was marked suspect, you may choose to remove its suspect flag if you are certain that the critical error which caused the database to be marked suspect has been resolved (for example, if one of the database devices was not available when SQL Server was booted and you are sure that the device is available now). If you cannot find any procedures recommended for your specific errors, call Sybase Technical Support for assistance. If the specified database does not contain important data or if you have a known, clean backup of it, you may choose to drop it first, re-create it, and then load the clean database dump into it. Refer to “How to Drop a Database When drop database Fails” in the SQL Server Troubleshooting Guide for information on how to drop a database that has been marked suspect. Before loading the database dump into the newly created database, make sure that the new database and the dumped database have the same data and log mapping, and the same user segment definitions. Refer to “Error 2558” on page 2-274 for information about how to do this. Additional Information
Comments
 
 3002 Severity Level 23  -  For SQL Server Releases Up to 4.9.x Attempt to dump database %.*s found logical page %ld when logical page %ld expected.  SYBASE SQL Server
This error occurs when SQL Server finds an unexpected page number during a database dump. This error is fatal and stops the dump from completing. Error 3002 is most likely caused by corruption of a database as a result of either: • Hardware failure • Inadvertently trying to use a raw partition for two separate purposes
Run dbcc checkalloc to determine whether your database has a bad page number or page header. If this is the case, dbcc checkalloc will display Error 2529. In this case, refer to “Error 2529” on page 2-254 to determine how to recover from this error. Hardware Errors • Check the SQL Server error log to see if there are other indications of hardware problems, such as kernel messages reporting I/O errors. • Check the operating system error log or diagnostics utilities for I/O errors. Raw Partition Misuse Refer to “Correct Use of Raw Partitions” in the SQL Server Troubleshooting Guide to determine whether a raw partition is being used incorrectly. Incompatible Drives Some drives which have their read-ahead cache enabled may cause Error 3002. Turning their read-ahead cache off clears the error. If you suspect that this is the cause of your corruption, contact your hardware vendor. In this case, rebooting SQL Server and restarting the dump might clear the error. Additional Information If none of the above actions have solved the 3002 error, call Sybase Technical Support. Before you call, have the following information on hand: • SQL Server release and EBF Rollup Level • SQL Server and Backup Server error logs • Operating system error log • Text of all error messages • Results from dbcc checkdb and dbcc checkalloc if possible
Comments
 
 2402 Severity Level 16  -  Error converting client characters into server’s character set. Some character(s) could not be converted.  SYBASE SQL Server
This error occurs during insertion of data (insert or bcp) when SQL Server fails to convert a character to the required character set. Error 2402 usually occurs for one of the following reasons: • The character exists in the client character set but it does not exist in the SQL Server character set. • The character exists in both the client and the SQL Server character set, but is represented by a different number of bytes in the client character set than in the SQL Server character set. This error occurs during normal processing and it prevents query execution.
The following options are available for recovering from Error 2402. Change Your Data Modify the incoming data so that it contains characters recognizable by SQL Server. Turn Off Character Set Conversion If the error occurs while you are using isql, bcp, or defncopy, you can use the -J (UNIX and PC) or /clientcharset (OpenVMS) command-line option with no character set name to set the client’s character set to NULL. If you use this command-line option without specifying a character set name, no conversion takes place and no error message is sent. As a result, some characters sent by the client to the SQL Server may not be interpreted correctly by the SQL Server and vice versa. (If only 7-bit characters are being handled, no incorrect interpretation will take place.) Otherwise, you can turn off conversion so that characters are sent and received unchanged with the following command: 1> set char_convert off 2> go Turn Off Character Set Conversion Error Reporting You can turn off the printing of error messages with the following command: 1> set char_convert on with no_error 2> go Bytes which cannot be converted are replaced with an ASCII question mark (“?”). Additional Information Refer to the System Administration Guide for details about character set conversion.
Comments
 
 Buffer Mismatch Error  -  server: Buffer "%d" from database "%s" has page number "%d" in the page header and page number "%d" in the buffer header.  SYBASE SQL Server
This error only appears in the error log, and it means that a cache management problem occurred. This can be a very serious error because it is often followed by database corruption, such as 605 errors. Although often a result of hardware failure, this error can also be caused by operating system or SQL Server problems.
If possible, shut down and restart SQL Server immediately after this error occurs. This may prevent the buffer cache error from being flushed to disk. Run complete diagnostics on the machine running SQL Server as well as on all disk drives and controllers attached to the SQL Server machine. Run complete dbcc checks on any databases involved, including dbcc checkalloc and dbcc checkdb. Repair or replace faulty hardware. Then, shut down SQL Server and restart it. If you do not find any hardware problems, call Sybase Technical Support immediately. Before calling Technical Support for assistance, have the following available: • SQL Server release and EBF Rollup level • SQL Server error log • Hardware error log • Text of all the error messages • Reproducible case (if possible)
Comments
 
 3202 Severity Level 16  -  Release 10.0 and Later Received MULTARG is not for device name as expected. Releases 4.9.x and Earlier Write on dump device '%.*s' failed, vsn=%ld return=%d status=%ld. Please consult the SQL  SYBASE SQL Server
Release 10.0 and Later The meaning of Error 3202 for SQL Server 10.0 and later is different from the meaning when it is raised on SQL Server 4.9.x and earlier. A MULTARG is a structure SQL Server stores in memory to keep information about the device being dumped to. If the dump routine was passed a MULTARG which is not for a dump device and you are running the Diagnostics Server (not likely), Error 3202 will be raised. If you receive Error 3202 when using SQL Server 10.0 or later, call Sybase Technical Support. Releases 4.9.x and Earlier For SQL Server 4.9.x and earlier versions, Error 3202 means that an error occurred when “writing” out a packet of data to the backup. Common causes are: • Running out of space for your dump (to disk) • A bad tape • A bad tape size • A bad block size • Hardware failure This error is fatal and stops the dump from completing. This invalidates the backup and makes it unusable for recovery purposes. The error message output includes: • vsn – the virtual socket number. • return – the return value: 0 means successful; -2 means failure. • status – the ending status, displayed in decimal value. The most common value is 524288 which usually means an I/O error. This status is Sybase-specific and has no operating system correlation.
The following actions apply only to SQL Server 4.9.x and earlier versions. If a 3202 error occurs on SQL Server 10.0 or later, call Sybase Technical Support. To determine the cause of the 3202 error, look at the message above the 3202 error in your SQL Server error log. You should see a generic message about a write to tape/disk failure during a dump database or dump transaction. Depending on the reason Error 3202 was raised, perform one of the following actions. Not Enough Space Error 3202 can occur in dumps to disk if the database you are dumping is larger than the size of the file you are dumping to. This limit can be user-imposed or system imposed. Under VMS, a user can assign a limit for size on individual files. Under many versions of UNIX, there is a 2GB file system size limit. If you have a database that exceeds these limits, dump the database to tape. Error 3202 can occur when dumping to tape if the tape runs out before the entire database has been dumped. You will encounter this if the size specified for the device via sp_addumpdevice is larger than the capacity of the device. Hardware Errors • Check the SQL Server error log to see if there are other indications of hardware problems, such as kernel messages reporting I/O errors. • Check the operating system error log or diagnostics utilities for I/O errors. Check your operating system error log for operating system errors. If no errors are logged in your operating system error log and
Comments
 
 601 Severity Level 21  -  Descriptor for system table '%ld' in database '%d' not found in the descriptor hash table.  SYBASE SQL Server
Release 10.0 and Later This error occurs when the SQL Server Threshold Manager could not open the systhresholds system table in a database because the descriptor for systhresholds was not found. SQL Server expects every database to have a systhresholds table. The failure to open systhresholds is probably due to corruption in the database named in the error message. Error 601 was not raised in SQL Server releases 4.8 and 4.9.x. Release 4.2 and Earlier This error occurs when the SQL Server could not open a system table in a database because the descriptor for that system table was not found. The failure to open the system table is probably due to corruption, either in memory or in the database itself.
1. Determine the name of the database from the database ID in the error message: 1> use master 2> go 1> select * from sysdatabases where dbid = ID 2> go where ID is the database ID from the error message. 2. Determine whether the system table object ID displayed in the error message exists: 1> use database_name 2> go 1> select * from sysobjects where id = object_ID 2> go where database_name is the name from step 1 and object_ID is the system table ID listed in the error message. 3. If the ID exists for the table displayed in the message, then the 601 error may be due to corruption in the memory structure used to hold the descriptor. Shutting down and restarting SQL Server should clear the problem. If this does not work, go on to step 4. 4. If the ID does not exist, there is probably corruption in your database. Do the following: 1. Run dbcc checkalloc, dbcc checkcatalog, and dbcc checkdb for the database. 2. Determine whether hardware problems exist by checking your operating system error log. 3. Call Sybase Technical Support. They may be able to help you recover your database, but you will probably have to recover your database from backups. Additional Information Before contacting Technical Support, be prepared to provide: • SQL Server release and EBF Rollup level • Complete text of all error messagesSQL Server error log output • Operating system error log output • dbcc checkalloc, dbcc checkcatalog, and dbcc checkdb output for the d
Comments
 
 os_create_region Errors  -  os_create_region: shmget (0x%x): %s os_create_region: Shared memory segment %d is in the way os_create_region: uninitialized shared memory descriptor os_create_region: shmat (%d): %s os_create SYBASE SQL Server
SQL Server uses the following functions to manage shared memory: • os_get_shmid – create a shared memory identifier • os_create_region – create a region based on a shared memory identifier • os_attach_region – attach to a region based on a shared memory identifier • os_detach_region – detach from (and delete) the shared region • os_format_shmid – format a shared memory identifier for printing When os_create_region errors occur, SQL Server will not start. The messages listed in this writeup are raised on UNIX systems only. Other operating systems raise slightly different errors. os_create_region: shmget (0x%x): %s This message is written to the error log when SQL Server fails to get a shared memory segment. In this message, %x is a shared memory key based on the shared memory identifier and %s is an operating system error message. os_create_region: Shared memory segment %d is in the way This error follows the shmget message and is also written to the SQL Server error log. A value of -1 for %d means the region does not exist. os_create_region: uninitialized shared memory descriptor During creation of a shared memory region, SQL Server attempts to validate the descriptor for the memory region. This message is written to the error log if the descriptor is found to be invalid. os_create_region: shmat (%d): %s This message is written to the error log when SQL Server fails to attach at an address. In this message, %d is the shared memory identifier and %s
1. At the operating system level, check which shared memory processes are using and whether shared memory segments are being used by SQL Server. To check this on UNIX, run this command as the “sybase” user: % ipcs -m IPC status from workstation1 as of Fri May 26 14:08:25 1995 T ID KEY MODE OWNER GROUP Shared Memory: m 256 0x699b7e24 --rw------- sybase sybase m 257 0x699b7e25 --rw------- sybase sybase If shared memory segments are being used by SQL Server, reboot the operating system to clear shared memory or remove them using the ipcrm operating system command. Before removing the shared memory segments, identify the process that created them using the command “ipcs -ma” to make sure you only remove the appropriate segments. 2. Check the $SYBASE directory to see whether there are any *.krg or *.srg files left from an abnormal SQL Server exit. If any such files exist, delete them. 3. os_create_region errors can occur when shared memory is not configured properly on your operating system. Refer to the System Administration Guide Supplement for your platform for information about configuring shared memory properly. Additional Information Refer to the operating system man pages for the shget() and shmat() system calls. Refer to the operating system man pages for ipcs and ipcrm.
Comments
 
 3703 Severity Level 11  -  Cannot drop the %S_MSG with object-id %ld in database %d, because it doesn’t exist in the system catalogs.  SYBASE SQL Server
This error occurs when SQL Server fails to drop a database, user table, procedure, rule, default, trigger, or view because the object being dropped does not exist in the appropriate system table. Error 3703 can occur during a drop command such as drop database, drop table, drop procedure, or drop rule. Error 3703 occurs with the following states. State Meaning 1 During a drop trigger command, if SQL Server fails to find the trigger or the target table of the trigger, Error 3703 occurs with State 1. 2 During a drop index command, if SQL Server fails to find the object ID of the table for which the index is being dropped in sysobjects, Error 3703 occurs with State 2. 4 During any drop command, if SQL Server fails to find a sysobjects entry for the object being dropped, Error 3703 occurs with State 4. 5 The sysconstraints table has one row for each referential and check constraint associated with a table or column. You can drop constraints using the alter table command. If, during such an alter table command, SQL Server fails to find an entry for the constraint in sysconstraints, Error 3703 occurs with State 5. 6 The sysreferences table has one row for each referential integrity constraint declared on a table or column. If the object being dropped is a referential integrity constraint, SQL Server searches sysreferences for the referential integrity constraint ID. If the ID is not found, Error 3703 occurs with State 6. 7 When SQL Server fails to drop a d
Recovering from Error 3703 requires manually modifying one or more system tables. Call Sybase Technical Support for assistance in determining which tables to modify and how to do it. Additional Information Before calling Technical Support, have the following information available: • SQL Server release and EBF Rollup level • Text of all error messages 8 If the database being dropped has referential dependencies, SQL Server tries to drop the references from the other databases. If the ID of the reference from the other database is not found in sysreferences, Error 3703 occurs with State 8. State Meaning Transaction Errors
Comments
 
 3701 Severity Level 11  -  Cannot drop the %S_MSG '%.*s', because it doesn’t exist in the system catalogs.  SYBASE SQL Server
This error occurs when you try to drop an object that is not found in at least one system table where SQL Server expected to find it. Error 3701 can occur due to the following circumstances: • The object you are trying to drop does not exist • Inconsistent system catalog tables • A SQL Server problem has occurred
Make sure you entered the object name correctly in your drop command. If you are entering the object name correctly and the drop fails with Error 3701, try to re-create the object. If your create command displays the message: Msg 2714, Level 16, State 1: Line 1: There is already an object named 'object_name' in the database. then your system tables are incorrect with regard to this object. If this occurs, run dbcc checkcatalog and dbcc checkdb. Then call Sybase Technical Support. They will probably be able to help you delete the object that is causing the error. However, because other objects may reference that object, deleting it cleanly may be difficult. If this is the case, you may need to recover from backups. Additional Information Before calling Technical Support, have the following information available: • SQL Server release and EBF Rollup level • Text of all error messages • Output of dbcc checkdb and dbcc checkcatalog
Comments
 
 

 
SQL Server System Error Messages  (939)
SQL Server Enterprise Manager Error Messages (5)
INFORMIX (3)
Visual Basic .Net Compiler Messages (1)
 
  Prev   1  2  3  4  5  6  7  8  9  10  Next