You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
default "no", if "yes" run the task in asynchronous mode
The status of a task running in asynchronous mode can be checked using the 'gettaskstatus' api
Only one of these database tasks — addvoldb, backupdb, checkdb, compactdb, copydb, createdb, deletedb, loaddb, optimizedb, renamedb, restoredb, startdb, stopdb, unloaddb — can run against the same dbname at a time, whether or not async is used; a request is rejected immediately if another one of them is already running on that database
if failed, a brief description will be given here; on a successful delete, may instead carry a warning that a manual check is recommended (see below)
Deleting the database itself is what status reflects. Afterward, CMS also does best-effort bookkeeping: removing the database's entries from its own user-authorization file (cmdb.pass) and from the auto-job config files (addvoldb/backupdb/history/execquery). If any of that bookkeeping fails - a lock timeout, a file I/O error, or an internal update error - the database is not restored; status still reports "success", and note instead names exactly which of those file(s) could not be updated and should be checked and cleaned up manually. This applies whether the task is run synchronously or with async:"yes" (see the async response samples below).
{
"__EXEC_TIME" : "401 ms",
"note" : "WARNING: database 'alatestdb' was deleted, but the following bookkeeping file(s) could not be updated (lock timeout, file I/O error, or an internal update error): cmdb.pass, the auto-job backupdb config file; manual check recommended",
"status" : "success",
"task" : "deletedb"
}