db:drop error not being caught

Thursday, 25 September 2025 · 5 messages · last reply 29 Sep 2025
LV
Lizzi, Vincent25 Sep 2025 21:14 #
Hi all, I have a query that is intended to delete outdated databases. This has been working but I recently found that if a database is locked the process stops with an error such as: [db:lock] Database 'name' cannot be updated, it is opened by another process. As a result, the process is stopped by any database being in a locked state. I would have thought that the try / catch around db:drop would catch the error and allow the process to skip over any locked databases.
declare variable $age external := 'PT1M'; (: age 1 minute for testing :)

let $cutoff := current-dateTime() - xs:dayTimeDuration($age)
let $databases := db:list-details()[xs:dateTime(@modified-date) lt $cutoff]
return (
  admin:write-log('cleanup delete items older than ' || $cutoff),
  for $db in $databases return (
    admin:write-log('cleanup deleting database ' || $db),
    try {
      db:drop($db)
    } catch * {
      admin:write-log('cleanup error deleting ' || $db || ': ' || $err:description, 'ERROR')
    }
  )
)
I tried replacing catch * with catch db:open to catch the specific error, but that hasn't helped. Why is the error not caught, and is there a better way to write this query to avoid this problem? Thanks, Vincent ______________________________________________ Vincent M. Lizzi Head of Information Standards | Taylor & Francis Group E-Mail: vincent.lizzi at taylorandfrancis.com<mailto:vincent.lizzi at taylorandfrancis.com> Web: www.tandfonline.com<http://www.tandfonline.com/> Time zone: US Eastern Taylor & Francis is a trading name of Informa UK Limited, registered in England under no. 1072954 "Everything should be made as simple as possible, but not simpler." [cid:8d80b1b7-f927-4cb7-a971-709e53dbf8b7]<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature> Book time to meet with me<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature>
CG
Christian Grün27 Sep 2025 09:05 #
Hi Vincent, Database updates are not immediately processed, but added to the so-called PUL (pending update list) [1] and executed at the very end of the query. When the updates are executed. This means that try/catch won’t have any effect, as the mere addition of the operation to the PUL does not raise any errors. The interesting question is why the error is raised at all. Do you have multiple independent instances of BaseX that access the same databases? If not, can you imagine an example that allows us to reproduce the behavior? Best, Christian [1] https://docs.basex.org/main/Updates#pending_update_list
Quoted text · Lizzi, Vincent · 36 lines
Von: Lizzi, Vincent via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Gesendet: Donnerstag, September 25, 2025 9:15:45 PM An: Christian Grün via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Betreff: [basex-talk] db:drop error not being caught Hi all, I have a query that is intended to delete outdated databases. This has been working but I recently found that if a database is locked the process stops with an error such as: [db:lock] Database 'name' cannot be updated, it is opened by another process. As a result, the process is stopped by any database being in a locked state. I would have thought that the try / catch around db:drop would catch the error and allow the process to skip over any locked databases. declare variable $age external := 'PT1M'; (: age 1 minute for testing :) let $cutoff := current-dateTime() - xs:dayTimeDuration($age) let $databases := db:list-details()[xs:dateTime(@modified-date) lt $cutoff] return ( admin:write-log('cleanup delete items older than ' || $cutoff), for $db in $databases return ( admin:write-log('cleanup deleting database ' || $db), try { db:drop($db) } catch * { admin:write-log('cleanup error deleting ' || $db || ': ' || $err:description, 'ERROR') } ) ) I tried replacing catch * with catch db:open to catch the specific error, but that hasn't helped. Why is the error not caught, and is there a better way to write this query to avoid this problem? Thanks, Vincent Vincent M. Lizzi Head of Information Standards | Taylor & Francis Group E-Mail: vincent.lizzi at taylorandfrancis.com<mailto:vincent.lizzi at taylorandfrancis.com> Web: www.tandfonline.com<http://www.tandfonline.com/> Time zone: US Eastern Taylor & Francis is a trading name of Informa UK Limited, registered in England under no. 1072954 "Everything should be made as simple as possible, but not simpler." [cid:8d80b1b7-f927-4cb7-a971-709e53dbf8b7]<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature> Book time to meet with me<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature>
LV
Lizzi, Vincent29 Sep 2025 06:00 #
Hi Christian, Thank you for this explanation. Based on your explanation, having try/catch around db:drop or any updating expression is not able to catch an error because the actual update is performed later. It may be just as well to remove the try/catch around db:drop. I encountered this specific error using BaseX GUI by running this script while a database was open. I was trying to reproduce a problem where this query (and a simplified version of it) got hung up trying to cleanup databases after BaseX gave out of memory errors. I haven't been able to identify what caused the original problem. I suspect that one of the (dozens of) databases got corrupted and even db:list() was not working. If db:list() is not working, is there any way to identify which databases might be corrupt, locked, or somehow causing a problem? Best regards, Vincent _____________________________________________ Vincent M. Lizzi Head of Information Standards | Taylor & Francis Group vincent.lizzi at taylorandfrancis.com<mailto:vincent.lizzi at taylorandfrancis.com> Time zone: US Eastern [cid:2bba9a86-d74f-4493-a109-7add9de4cf97]<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature> Book time to meet with me<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature>
Quoted text · Christian Grün · 47 lines
From: Christian Grün <cg at basex.org> Sent: Saturday, September 27, 2025 3:05 AM To: Lizzi, Vincent <Vincent.Lizzi at taylorandfrancis.com>; Christian Grün via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Subject: Re: db:drop error not being caught Hi Vincent, Database updates are not immediately processed, but added to the so-called PUL (pending update list) [1] and executed at the very end of the query. When the updates are executed. This means that try/catch won’t have any effect, as the mere addition of the operation to the PUL does not raise any errors. The interesting question is why the error is raised at all. Do you have multiple independent instances of BaseX that access the same databases? If not, can you imagine an example that allows us to reproduce the behavior? Best, Christian [1] https://docs.basex.org/main/Updates#pending_update_list<https://docs.basex.org/main/Updates#pending_update_list> Von: Lizzi, Vincent via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Gesendet: Donnerstag, September 25, 2025 9:15:45 PM An: Christian Grün via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Betreff: [basex-talk] db:drop error not being caught Hi all, I have a query that is intended to delete outdated databases. This has been working but I recently found that if a database is locked the process stops with an error such as: [db:lock] Database 'name' cannot be updated, it is opened by another process. As a result, the process is stopped by any database being in a locked state. I would have thought that the try / catch around db:drop would catch the error and allow the process to skip over any locked databases. declare variable $age external := 'PT1M'; (: age 1 minute for testing :) let $cutoff := current-dateTime() - xs:dayTimeDuration($age) let $databases := db:list-details()[xs:dateTime(@modified-date) lt $cutoff] return ( admin:write-log('cleanup delete items older than ' || $cutoff), for $db in $databases return ( admin:write-log('cleanup deleting database ' || $db), try { db:drop($db) } catch * { admin:write-log('cleanup error deleting ' || $db || ': ' || $err:description, 'ERROR') } ) ) I tried replacing catch * with catch db:open to catch the specific error, but that hasn't helped. Why is the error not caught, and is there a better way to write this query to avoid this problem? Thanks, Vincent Vincent M. Lizzi Head of Information Standards | Taylor & Francis Group E-Mail: vincent.lizzi at taylorandfrancis.com<mailto:vincent.lizzi at taylorandfrancis.com> Web: www.tandfonline.com<http://www.tandfonline.com/> Time zone: US Eastern Taylor & Francis is a trading name of Informa UK Limited, registered in England under no. 1072954 "Everything should be made as simple as possible, but not simpler." [cid:8d80b1b7-f927-4cb7-a971-709e53dbf8b7]<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature> Book time to meet with me<https://outlook.office.com/bookwithme/user/aa80d42cbb5b46dba06a5ad241d7665b at taylorandfrancis.com?anonymous&ep=owaSlotsEmailSignature> Information Classification: General
CG
Christian Grün29 Sep 2025 10:44 #
Hi Vincent,
Quoted text · Lizzi, Vincent · 1 line
> I encountered this specific error using BaseX GUI by running this script while a database was open.
I see: Mixing the GUI and other independent BaseX instances may indeed unexpected errors.
Quoted text · Lizzi, Vincent · 1 line
> If db:list() is not working, is there any way to identify which databases might be corrupt, locked, or somehow causing a problem?
In principle, db:list() (without arguments) is nothing else than a file:list() operation for the database directory. You should be able to simulate it with:
  for $db in file:children(db:option('dbpath'))
  where file:is-dir($db)
  return file:name($db)
Do you remember what happened when you tried to use db:list? Best, Christian
LV
Lizzi, Vincent29 Sep 2025 15:22 #
Hi Christian, From what I recall, when the problem was happening db:list() ! db:drop(.) hung and db:list-details was slow to respond then gave an out of memory error. The solution at the time was to delete all databases using an operating system command, since the databases are temporary in nature. That resolved the immediate problem, fortunately. However, I'm not able to inspect the files now to find the origin of the problem. If it's possible, if like to add more error logging, monitoring, or some way to identify if a database is corrupted, just in case any similar problem happens again. Thank you, Vincent This message was sent from a mobile device. Information Classification: General
Quoted text · Christian Grün · 15 lines
From: Christian Grün <cg at basex.org> Sent: Monday, September 29, 2025 4:44:42 AM To: Lizzi, Vincent <Vincent.Lizzi at taylorandfrancis.com>; Christian Grün via BaseX-Talk <basex-talk at mailman.uni-konstanz.de> Subject: AW: db:drop error not being caught Hi Vincent, > I encountered this specific error using BaseX GUI by running this script while a database was open. I see: Mixing the GUI and other independent BaseX instances may indeed unexpected errors. > If db:list() is not working, is there any way to identify which databases might be corrupt, locked, or somehow causing a problem? In principle, db:list() (without arguments) is nothing else than a file:list() operation for the database directory. You should be able to simulate it with: for $db in file:children(db:option('dbpath')) where file:is-dir($db) return file:name($db) Do you remember what happened when you tried to use db:list? Best, Christian

⚡Generated with XQuery