This section contains error messages for the Open Database Manager.
Most 9xx errors are encountered during recovery. Many of these errors may be raised as a result of the master database being corrupt. If this is the case, refer to the System Database Recovery chapter for help.
23
Unable to find row in sysindexes for clustered index on system catalog %d in database %d. This index should exist in all databases. Run DBCC CHECKTABLE on sysindexes in the database.
This error may be caused by a hardware problem.
This error occurs when Adaptive Server is unable to access the sysindexes table for a database.
Error 903 can occur under the following circumstances when Adaptive Server accesses sysindexes:
Actions that involve opening a database since those actions access the sysindexes table for that database (for example, database recovery)
Actions that need to access columns in sysindexes. Such actions include:
order_by clause compilation.
Running the update statistics command.
Threshold Manager space calculations. Refer to “Managing Free Space with Thresholds” in the System Administration Guide for information about thresholds.
Possible causes of Error 903 are:
A problem has occurred with the device on which sysindexes resides and sysindexes has become corrupted.
The partition on which the database resides has been mounted as a file system or overlapping partitions exist. Refer to “Correct Use of Raw Partitions” in the Encyclopedia of Tasks chapter.
An Adaptive Server problem.
Determine whether the device on which the database resides is damaged and solve any problems that exist.
If the database named in the error message is accessible, run dbcc checkdb and dbcc checkcatalog to determine whether the database is corrupted. If the database is corrupted, restore it from backup.
If you cannot find any device problems and the database is not corrupted, call Sybase Technical Support.
Before calling Technical Support, have the following information available:
Server version and SWR version level
select * from database_name..sysindexes where id=object_id("sysindexes") output
dbcc checkdb and dbcc checkcatalog output
Text of all the error messages
All versions
17
Unable to allocate a DBTABLE descriptor to open database ’%S_DBID’. Close or drop another database before opening this one, or ask your System Administrator to raise the configuration parameter ’number of open databases’.
As part of open database processing, the Database Table Manager controls and synchronizes access to database tables. When Adaptive Server tries to open a database and there are not enough database descriptors available, Error 905 occurs. (The total number of database descriptors available is controlled by the number of open databases configuration parameter.)
The action in the text of the 905 message only applies to environments where:
You cannot have any more open databases (for instance, because of memory limitations), or
You cannot increase the value of the number of open databases configuration parameter until a later date because you cannot shut down and restart Adaptive Server at this time.
When Error 905 occurs, select one of the following strategies to solve the problem.
In the short term, you can close or drop another database. This is not a long-term solution. You can use this option until an Adaptive Server restart can be scheduled, as a restart is necessary for the long-term solution.
To close a database, make sure no users are accessing the database or put the database into single-user mode. This does not guarantee that the database will not be accessed by Adaptive Server (for example, for an automatic checkpoint), so the 905 error may still occur.
As a long-term solution, use sp_configure to increase the value of the number of open databases configuration parameter:
Determine your current value:
1> sp_configure "number of open databases" 2> go
Determine what your new value should be. One way to do this is to determine the number of databases you have now and then add a padding factor for future growth.
For example:
1> select count(*) from sysdatabases 2> go
-----------
12
Set the new value. For example:
1> sp_configure "number of open databases", 15 2> go
where “15” is the new value (12 existing databases plus a padding factor of 3 for future growth).
Shut down and restart Adaptive Server to put the new value in effect.
If you increase the value of the number of
open databases configuration parameter, make sure you
reconfigure Adaptive Server memory appropriately. 17,408 bytes are
required for each additional open database. Refer to “Configuring
Memory” in the System Administration Guide and
the Performance and Tuning Guide for information
about Adaptive Server memory use.
All versions
23
Could not locate row in sysobjects for system catalog %d in database %d. This system catalog should exist in all databases. Run DBCC CHECKTABLE on sysindexes in the database.
This error may be caused by a hardware problem.
Adaptive Server expects to find certain information in static locations within a database or on the Server:
Page 1 of each database is the first page for sysobjects
Page 24 of each database is the first page for sysindexes
As part of open database processing, the Descriptor Manager searches page 1 for entries for sysobjects and page 24 for entries for sysindexes. If the entries are not found on the expected page, Error 906 will occur.
Error 906 occurs during open database actions such as recovery and create database.
Possible causes of Error 906 are:
The partition on which the database resides has been mounted as a file system or overlapping partitions exist. Refer to “Correct Use of Raw Partitions”.
A database device has been created that exceeds the operating system maximum size limit (for example, 2GB on some 32-bit machines).
Error 906 means that, for the database specified in the message, either page 1 or page 24 is corrupted. Restore that database from backup.
All versions
22
Unable to find any entries in Sysusages for dbid '%d',database '%.*s'. Run DBCC CHECKTABLE on Sysusages in the master database.
The master..sysusages table keeps track of the space that you assign to Adaptive Server databases. create database and alter database allocate new space to the database by adding a row to sysusages for each database device or device fragment.
The Adaptive Server Database Manager maps logical pages (pages in an Adaptive Server database) to virtual pages (pages in a database device). There is a one-to-one correspondence between these two types of pages.
Error 908 occurs during recovery when Adaptive Server attempts to generate the mapping of logical to virtual pages for a specified database, but is unable to find any rows for the database in the sysusages table.
Check the sysusages table:
1> use master 2> go 1> dbcc checktable(sysusages) 2> go
If errors are reported, try to fix them using the sections in this manual that describe those errors.
If dbcc checktable reported no errors, and you do not need to recover the database in question, remove the database from your Adaptive Server installation. For further information, refer to “How to Drop a Database When drop database Fails” in the Encyclopedia of Tasks chapter. After removing the database, restart Adaptive Server and check that the 908 error is eliminated.
If dbcc checktable reported no errors, but you need to recover the database in question, start by removing the database from your Adaptive Server installation as described above. Next, rebuild the database using your creation scripts, and reload it from a clean backup.
All versions
16
Attempt to locate entry in sysdatabases for database '%.*s' by name failed - no entry found under that name. Make sure that name is entered properly.
This error may be caused by a hardware problem.
This error occurs during a use command when Adaptive Server tries to access a database that is not listed in sysdatabases. For example:
A user tries to access a database not listed in sysdatabases:
1> use database_name 2> go
A user tries to connect to Adaptive Server when an invalid database is indicated by the defaultdb column of master..syslogins. The user is connected only to master, or not connected at all, and Error 911 occurs.
Obtain a list of all databases in sysdatabases by executing sp_helpdb or the following:
1> select name from master..sysdatabases 2> go
The list returned contains the only valid databases recognized by Adaptive Server and available for use.
Either create the missing database or change the reference to a database from the list created in step 1:
If a user-issued use command created the error, either create a database following regular procedures (refer to “Creating and Managing User Databases” in the System Administration Guide) or change the use command to refer to one of the databases from the list created in step 1.
If the defaultdb option of sp_addlogin refers to an invalid database, the System Administrator (“sa”) or user needs to specify a new, valid, default database. To specify a new default database, choose a database name from the list in step 1 and use the following procedure:
1> sp_modifylogin user_name, defdb, database_name 2> go
Although you can successfully change your own default database at any time with sp_modifylogin, you can access the database only if the database owner (“dbo”) has added you as a user in the database.
Refer to the Adaptive Server Enterprise Reference Manual for information about sp_addlogin and sp_modifylogin.
All versions
22
Could not find row in sysdatabases with database id %d. Run DBCC CHECKTABLE on sysdatabases.
This error occurs when Adaptive Server cannot find an entry in sysdatabases when looking for a specific database ID.
Possible causes of Error 913 are:
Accessing a stored procedure or view that refers to a table in a database that has been dropped.
Accessing a stored procedure or view that refers to a table in a database that has been dropped and re-created.
A nonclustered index on the sysdatabases table in the master database has been corrupted.
This is a serious error if the index is corrupt or recovery fails.
If the 913 error is caused by accessing a stored procedure or view that refers to a table in a database that has been dropped, either re-create the database or update the procedure or view to point to the appropriate database.
When a database has been dropped and re-created, it can end up with a different database ID. If a stored procedure still references the old database ID, drop and re-create the stored procedure so that it will reference the new database ID. Refer to drop procedure and create procedure in the Reference Manual for information about dropping and re-creating stored procedures.
If the cause of the error is a corrupted nonclustered index on a system table, use one of these options:
Use the sp_fixindex stored procedure to repair the index.
Restore master from backup. Refer to Chapter 1, “System Database Recovery” for information about restoring the master database.
All versions
14
Server user id %d is not a valid user in database '%.*s'
When a user tries to open a database, Adaptive Server performs the following checks to determine the validity of the user:
Looks for the suid (Adaptive Server user ID, copied from syslogins) of the process in sysusers to find the corresponding uid (user ID, unique in this database) and gid (group ID to which this user belongs).
Looks for a “guest” row in sysusers (the suid for “guest” is -1).
Looks for the user ID in sysalternates.
Checks sysusers to determine whether the user has “sso” role if the user does have an suid in the database. This check is related to Adaptive Server auditing.
Error 916 occurs when a user tries to open a database and Adaptive Server finds that the user ID is not valid.
Decide whether you want the user to access the database with:
A normal login and user ID
A guest user ID
An alias to another user ID
If you want the user to access the database with a normal login and user ID, determine whether the Adaptive Server user ID exists in the current database:
1> use database_name 2> go
1> select * from sysusers 2> where suid = Server_user_ID 3> go
where Server_user_ID is the Adaptive Server user ID displayed in the error message. If the user is not found, use sp_adduser to add them.
If the user is found and you are getting Error 916 for that user, run dbcc checkdb on the database to find out whether it is corrupt. If dbcc checkdb returns error messages, corruption has occurred. Follow the directions in this manual for recovering from those errors.
If you want the user to access the database as guest, determine whether there is a “guest” row in sysusers of the database being opened:
1> use database_name 2> go
1> select * from sysusers 2> where suid = -1 3> go
where database_name is the name of the database in the error message. If guest is not found, use sp_adduser to add it.
If guest is found, run dbcc checkdb on the database the user is trying to access to find out whether it is corrupt. If dbcc checkdb returns error messages, corruption has occurred. Follow the directions in this manual for recovering from those errors.
If you want the user to access the database with an alias to another user, determine whether the user ID exists in sysalternates of the database being opened:
1> use database_name 2> go
1> select * from sysalternates 2> where suid = Server_user_ID 3> go
If the user ID is not found, use sp_addalias to add an alias for them.
If the user ID is found and you are getting Error 916 for that user, run dbcc checkdb on the database the user is trying to access to find out whether it is corrupt. If dbcc checkdb returns error messages, corruption has occurred. Follow the directions in this manual for recovering from those errors.
If the database is being accessed due to a referential constraint, make sure the user ID exists in each database.
If Error 916 occurs after the above actions have been taken, call Sybase Technical Support.
Refer to the Reference Manual for information about sp_addlogin, sp_adduser, and sp_addalias.
Have the following information ready when you call Sybase Technical Support:
Server version and SWR rollup level
Text of all error messages
Output from syslogins
Output from sysusers and sysalternates for the database being opened
All versions
14
Database '%.*s' has not been recovered yet - please wait and try again.
This error occurs during the database recovery phase of Adaptive Server startup when you try to access a database for which recovery has not yet been completed. It can also occur if the database was marked suspect due to an earlier problem.
If the database has been marked suspect by an earlier problem, this is a serious error and must be corrected if you want to access your database again.
The time it takes to recover a database depends on:
The number and size of transactions that must be committed or rolled back
The amount of memory
Determine whether the recovery phase of the database has completed:
Examine your Adaptive Server error log
Enter two select * from sysprocesses where spid=1 commands about 20 seconds apart. Find the spid of the process doing the recovery (the value of spid for the process doing database recovery is always “1” during Adaptive Server startup) and determine whether physical_io is increasing over time. If it is, recovery is still in progress.
If the database is still being recovered, wait until recovery is complete and then try to access the database.
If you are still unable to access the database and the database has been marked suspect because of an earlier problem, determine what the earlier problem was by looking at the Adaptive Server error log. Follow the instructions in this manual for recovering from that error. If no instructions exist, call Sybase Technical Support.
Before calling Technical Support, have the following information available:
Server version and SWR version level
Server error log, including boot sequence and all errors
Operating system error log
select * from master..sysusages output
select dbid, name, status from sysdatabases output
Text of all the error messages
All versions
14
Database '%.*s' is already open and can only have one user at a time.
This error occurs when an attempt is made to access a database that has been set to single-user mode and is being accessed by another user. Only one user at a time can access a database that is set to single-user mode.
Verify that the database being accessed is in single-user mode:
1> sp_helpdb database_name 2> go
If the database is in single-user mode you will see “single user” in the status column along with any other options that are set for the database.
Execute sp_who to determine who is accessing the database. Look for the database name under the dbname column and the login name in the loginame column.
Contact the individual and arrange for database access or contact your System Administrator (“sa”). The “sa” or database owner (“dbo”) can set the database to multi-user access when the database is not in use by executing the following from the master database:
1> sp_dboption database_name, single, false 2> go
1> use database_name 2> go
1> checkpoint 2> go
Refer to the Reference Manual for information about sp_dboption.
All versions
19
Maximum number of used databases for each query has been exceeded. The maximum allowed is %d.
Adaptive Server has an eight-level-deep stack of open databases for each process. Every time a database is opened, it gets pushed onto the stack, and when it is closed, it is removed from the stack.
There is usually one open database for each process. If you run a query that uses a table in a different database, Adaptive Server opens that database just long enough to use the table and then closes the database.
Sometimes, however, a database must remain open longer. For example, if you execute a stored procedure in a different database than the one you are currently using, Adaptive Server will open that database and keep it open until the stored procedure finishes.
Only eight databases can be open at once. A single database opened multiple times is added to the stack each time it is opened. This can result in Error 925, even though only one database has been used. If you have stored procedures that call other procedures in other databases, you can exceed this limit.
The use database_name command
closes the database that was previously open, so Error 925 would not be
generated by eight use database_name commands
in a row in Transact-SQL.
An example of a set of queries that exceeds the eight-level limit follows:
1> use db9 2> go
1> create proc pr9 2> as 3> select * from table1 4> go
1> use db8 2> go
1> create proc pr8 2> as 3> exec db9..pr9 4> go
1> use db7 2> go
1> create proc pr7 2> as 3> exec db8..pr8 4> go
1> use db6 2> go
1> create proc pr6 2> as 3> exec db7..pr7 4> go
1> use db5 2> go
1> create proc pr5 2> as 3> exec db6..pr6 4> go
1> use db4 2> go
1> create proc pr4 2> as 3> exec db5..pr5 4> go
1> use db3 2> go
1> create proc pr3 2> as 3> exec db4..pr4 4> go
1> use db2 2> go
1> create proc pr2 2> as 3> exec db3..pr3 4> go
1> use db1 2> go
1> create proc pr1 2> as 3> exec db2..pr2 4> go
Be aware of the eight-level open database limit when writing queries.
If you believe Error 925 is occurring for a reason other than a query that has more than eight database openings, restarting Adaptive Server should clear the problem.
All versions
14
Database '%.*s' cannot be opened. An earlier attempt at recovery marked it 'suspect'. Check the SQL Server errorlog for information as to the cause.
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 Adaptive 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 a hardware problem.
Error 3414 is a related error which occurs during startup when Adaptive Server cannot complete the recovery of a database. Refer to Error 3414.
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 Adaptive 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 Adaptive Server was started and you are sure that the device is available now). If you choose to reset the suspect status, refer to “How to Reset a Database's “suspect” Status” in the Encyclopedia of Tasks chapter.
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 Encyclopedia of Tasks chapter 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 for information about how to do this.
Before calling Technical Support, have the following information available:
Server version and SWR version level
Server error log, including boot sequence and all errors
Operating system error log
select * from master..sysusages output
select dbid, name, status from sysdatabases output
Text of all the error messages
All versions
14
Database '%.*s' cannot be opened because either an earlier system termination left LOAD DATABASE incomplete or the database is created with 'for load' option. Load the database or contact a user with System Administrator (SA) role.
This error occurs when you attempt to reference a database:
Whose load database process has been terminated before completion, or
That was created with the for load option and that has not been loaded yet.
Eliminate the 930 error by determining which of the above situations applies to you and then following the appropriate set of steps below.
Since the 930 error is, in this case, the result of an earlier error, the recommended action is to determine what caused the load database process to be terminated before completion.
Check the Adaptive Server and Backup Server error logs for error messages about the database in question, and try to eliminate those first by using the troubleshooting procedures in this manual. If you cannot find any procedures recommended for your specific errors in this manual, call Sybase Technical Support for assistance.
Examine your operating system error log to determine if hardware errors may have caused the corruption. If errors of this type occurred, solve the problem that caused them.
Enter the load database command again.
Load the database before you try to reference it.
If you do not have enough space allocated to the specified database and get Error 3105 when you attempt to load the database, use one of the following methods to increase the size of the database to be loaded:
Drop the newly created database first and then re-create it with the size specified in the Error 3105 message. If you cannot drop the database with drop database because the database has been marked suspect, and you are getting Error 926, refer to “How to Drop a Database When drop database Fails”.
Or:
Use the command alter database db_name for load.
To avoid 2558 errors or a remapped database, the database being loaded into must be identical to the dumped database in terms of data, log, and segment mapping. Refer to Error 2558 for more information.
If the specified database is the default database for a certain user, that user will get Errors 930 and 4001 and will be put in the master database when they connect to the Adaptive Server. Use the following command if you want to change that user's default database:
1> sp_modifylogin user_name, defdb, database_name 2> go
Before calling Technical Support, have the following information available:
Server version and SWR version level
Server error log
Backup Server error log
Operating system error log
select * from master..sysusages output
select * from master..sysdatabases output
Text of all the error messages
All versions
10
WARNING - the timestamp in database '%.*s' is approaching the maximum allowed.
Each database has one global timestamp which is kept in memory in a structure called a dbtable. The timestamp is not a date and time; rather, it is a sequence number which keeps track of modifications of pages within the database. Each time a page in the database is modified, the page gets the current timestamp and the global timestamp gets incremented. The global timestamp “travels” with a database through dumps, loads and upgrades. Timestamps are critical during recovery, to ensure that transactions are properly rolled forward or rolled back. The global timestamp is also used for timestamp columns.
The maximum value for timestamps is very high (0xffff 0xffffffff), so it is very unlikely that under normal circumstances a database will reach this limit. However, use of some unsupported database maintenance commands can cause a higher than expected global timestamp value.
Each time dbtable is created for the database, Adaptive Server checks whether the timestamp value is approaching the maximum by comparing the current timestamp value with a threshold value defined by Adaptive Server. Error 935 is raised if the timestamp value exceeds this threshold.
Error 935 gives you advance warning about a serious impending problem.
WARNING! After Error 935 is raised, only a few more transactions are possible in the database. If you do not address the problem, the timestamp value will reach the maximum and the database will no longer be usable.
Database dump/load is not an option to address this problem. When you receive Error 935, re-create the database in question as soon as possible using these steps:
bcp out all table data.
defncopy out all procedures, rules, defaults and triggers.
Use the drop database command to drop the database.
Use the create database command to re-create the database.
Create all tables.
bcp in all table data.
Create indexes.
defncopy in all procedures, rules, defaults and triggers.
Check that the user IDs in sysusers in the restored database are consistent with master..syslogins. Mismatched user IDs in databases can lead to permission problems.
Scripts are recommended for reliable re-creation of the database objects.
Refer to the glossary for additional information about timestamps and dbtable. Refer to “Developing a Backup and Recovery Plan” in the System Administration Guide for complete information about how to safely re-create databases.
All versions
26
Dbtable in wrong state for operation: %S_DBT.
Adaptive Server tracks the status of each open database using a memory structure called a dbtable, which contains state information such as the number of open transactions in the database, the number of open objects, keep counts that ensure proper use of each dbtable, and so on. Error 940 is raised when a database operation is attempted which is incompatible with the current state of its dbtable.
Error 940 is due to an internal Adaptive Server problem. It results in a stack trace and prevents further work in the server.
The error is raised with the following states:
State |
Meaning |
|---|---|
1 |
Database is being dropped but the dbtable is not marked for dropping. |
2 |
dbtable was marked for dropping by a task other than the one dropping the database. |
3 |
Database is being dropped but the dbtable’s keep count is not zero. This state is only raised by diagserver. |
4 |
Database is being dropped but is not marked active. |
5 |
dbtable is being locked but the database is not active. |
6 |
While decrementing the dbtable keep count, it was found to be less than zero. |
7 |
Illegal attempt by a process to increment the keep count. |
8 |
Similar to state 7. |
10 |
Invalid pointer to dbtable structure. |
11 |
While terminating use of a dbtable, the keep count was found to be less than zero. |
12 |
Attempted to unlock a dbtable which is not currently locked. |
13 |
Attempted to cleanup a dbtable not marked for cleanup. |
14 |
A non-system task attempted to update the keep count. |
15 |
Attempted to update a newly created dbtable which is not marked as created. (Raised by diagserver.) |
16 |
Similar to state 14 |
17 |
Attempted to free a dbtable not marked for cleanup. (Raised by diagserver.) |
18 |
Attempted to free a dbtable whose keep count is not 1. |
19 |
Retrieved a dbtable from the free list, but the dbtable is not marked as free. |
20 |
Illegal attempt to mark a dbtable active (raised by diagserver). |
21 |
Illegal attempt by a process that does not own a dbtable to keep it. |
22 |
Attempted to uninstall a dbtable that is not in the appropriate state ((raised by diagserver). |
23 |
Attempted to uninstall a dbtable that is not on the active chain. |
25 |
Database is not in ’drop’ state as expected. |
26 |
dbtable was found to be free although it is not marked free. |
27 |
dbtable was found to be free although its keep count is non-zero. |
29 |
dbtable is found to be active although it is not marked active. |
30 |
More than one dbtable is found for a database. |
Shut down and restart the server. If the problem persists, call Sybase Technical Support. You may need to upgrade to a version in which the problem is resolved.
Have the following information ready when you call Technical Support:
Server version and SWR rollup level
Server error log
11.5.1 and earlier
20
Illegal database context operation.
The Adaptive Server Database Context Manager controls access to databases. Any process opening or closing a database must do so through this subsystem, which maintains a list of open databases, the server user ID (suid) accessing the database, and other information in memory. The manager also accesses the Process Status Structure (PSS), which is a memory structure associated with each process describing the state of the process and usage of various resources used by the process.
Error 941 is raised when the Database Context Manager encounters a problem in fulfilling a database context change request.
Error 941 occurs with the following states:
State |
Meaning |
1 |
A request is made to close the current database and return the context to the previous database for the requestor. However there is no previous database on the context list. |
2 |
A request is made to close the last database open for the requestor. However the context list indicates that this is not the last open database. |
3 |
A database close request does not include a context for the action (such as returning to the previous database). |
4 |
A request is made to initialize the context list. However the list is not empty and cannot be initialized. |
Error 941 is due to corruption of the PSS or other memory structures.
Shut down and restart Adaptive Server to clear any memory corruption. If the problem persists, increase the value of the number of open databases parameter.
All versions
21
Unable to locate page %ld for database id %d in the in-memory copy of Sysusages (spid=%ld). This is an internal error. Please contact Sybase Technical Support.
Function %s was asked to locate page %ld in database %ld. The page number is invalid for the database.
This error may be caused by a hardware problem.
When the Adaptive Server Open Database Manager requests a page (for allocating extents and a number of other operations), it receives a page number and a pointer to a disk map array. It then determines the index of the map element that contains the target page and returns that index. When Adaptive Server cannot find the requested page number in the database disk map array, Error 945 occurs.
Possible causes of Error 945 are:
Memory corruption.
Bad allocation page pointers (sysusages table corruption).
Shut down and restart Adaptive Server. If the corruption is in memory, this should clear the 945 error. If Error 945 persists, go on to step 2.
Check your record of sysusages information for the database in the error message against what is currently in master..sysusages. (If you do not have a record of your sysusages information, try sp_help database_name to get a subset of the sysusages information.) To determine the sysusages information currently held by Adaptive Server, type:
1> select * from sysusages where dbid = database_ID 2> go
where database_ID is the number from the error message output.
If the information you have on record for that database does not match what is currently in sysusages, refer to “Restoring Device and Database Information in the System Catalog” in the Encyclopedia of Tasks chapter for information about restoring a corrupted sysusages table.
If the information you have on record for that database matches what is currently in sysusages, the database specified in the error message is corrupt. Restore the database from known, clean backups.
All versions
14
Database '%.*s' is currently offline. Please wait and try your command again later.
The Adaptive Server Database Context Manager controls access to databases. Any process opening or closing a database must do so through this subsystem. Error 950 is raised when the Database Context Manager is unable to honor a database access request because the database is offline, and is not available for general use.
During a load database, Adaptive Server takes the database being loaded offline, and the database remains in this state until it is brought back online.
During an Adaptive Server installation upgrade, a database is marked offline when loading the transaction log that is to be upgraded. You may see 950 errors:
If the load completed and the upgrade was successful, but the database was not brought back online.
If the upgrade failed, leaving the database offline.
If a load is in progress, complete the load sequence (including any loads of transaction log dumps), then use online database to make the database available for use.
If this error is raised due to an upgrade failure, the corrective action depends on several factors:
The original Adaptive Server version, and the version to which you are upgrading.
The phase of the upgrade process where failure occurred.
Whether the database(s) being upgraded has tables or other objects marked for replication. If the transaction log is not drained because log records are waiting to be processed by the Log Transfer Manager, the upgrade process for that database will fail, leaving the database offline.
Refer to "Recovering From a Failed Installation or Upgrade" in the Installation and Configuration Guide for your platform to determine how to proceed.
If you use Replication Server, you must disable replication before attempting to upgrade. Refer to your platform’sAdaptive Server installation guide for further information. For example, if upgrading to version 12.5, see "Preparing to upgrade servers with replicated databases" in the installation guide.
Have the following information ready when you call Sybase Technical Support:
Server version and SWR rollup level
Text of all error messages
All versions
