if (us < max_wait) {
// Success, but we waited at least once:
qDebug() << "Waited for QFile::remove() in microseconds: " << us.count(); // <== need to use ".count()" here...
} else {
// etc.

https://codebrowser.dev/qt6/qtbase/src/corelib/io/qfile.cpp.html#421
https://codebrowser.dev/qt6/qtbase/src/corelib/io/qfile.cpp.html#452

Does this help?

And since there is basically no difference in the actual code, as I said ... I do want to get the error message.

there is nothing between the QFile x(...) statement and the #ifdef....

 QFile x(absFilePath);
 x.close();

Then I have no idea why you are creating any QFile instance here at all. And if for unknown reason it is causing problem just remove it, why have you put this in? Oh, did you say purely in order to be able to go x.remove() so that you can get QFile::error() information for message? Certainly you should not need the close(), and I asked earlier if your if (x.isOpen()) was ever true, because with this code it should never be?

Looks like we shall never know why this fails when the static call succeeds....

  QString errstring;

  if (delete_existing_file) {
    std::chrono::microseconds us(0);
    const std::chrono::microseconds us_begin(0);
    const std::chrono::microseconds interval(500);
    const std::chrono::microseconds max_wait(1000000);
    { // start a new scope...
      QFile x(absFilePath);
      x.close();
      // The following snippet taken from the example for std::this_thread::yield():
      // https://en.cppreference.com/w/cpp/thread/yield.html
      auto wait_for_remove = [](std::chrono::microseconds s) {
        auto begin = std::chrono::high_resolution_clock::now();
        auto end = begin + s;
        do {
          std::this_thread::yield();
        } while(std::chrono::high_resolution_clock::now() < end);
      };

      while (!x.remove()) {
        us += interval;
        wait_for_remove(interval);
        if (us >= max_wait)
          break;
      }
      errstring = x.errorString();
    } // x goes out of scope here...

    if (us > us_begin) {
      if (us < max_wait) {
        // Success, but we waited at least once:
        qDebug() << "Waited for QFile::remove() in microseconds: " << us;
      } else {
        title = tr("Problem Removing Existing File");
        msg = tr("The file '%1' could not be removed.\n\nError message:\n%2")
                .arg(absFilePath).arg(errstring);
        QMessageBox::warning(this,title,msg);
        qDebug() << "Failed to remove file: " << absFilePath << "Error: " << errstring;
        return;
      }
    }
  }

@Robert-Hairgrove
to be 100% clear, the absFilePath is the path to the actual database file on disk opened by QSqlDatabase, right?

No ... absFilePath is the name of the file chosen by the user which will be the name of the new database. It just so happens that this is an existing file in this part of the code, which happens to be a database. There is no open database connection when this code runs, and there is nothing between the QFile x(...) statement and the #ifdef.... The application ensures that any open database is closed (i.e. the connection is removed) before letting the user create a new one.

Like @IgKh said, it is pretty much what is in the Qt source code for QFile::remove() ... it also closes the file before trying to remove it. And if it isn't open, then I assume there is no need to call close(). But maybe I should not trust QFile::isOpen() and just call close() in any case?

    QFile x(absFilePath);

#ifdef Q_OS_WINDOWS
    if (x.isOpen()) {
      x.close();
    }
#endif

    if (!x.remove()) {

• Put in a debug, do you actually hit that x.close()?
• Please show what you actually do with the QFile x in between creating the variable and the close for the attempted remove.

Oh, and to be 100% clear, the absFilePath is the path to the actual database file on disk opened by QSqlDatabase, right?

I need to look at the Qt source code some more ... if all else fails, I can try putting the call to QFile::remove() in a while loop and call std::yield or QApplication::processEvents().

Also, assuming you are using QSqlDatabase, have you done what you're not supposed to do and kept a member variable copy of it?

The tip about calling GetLastError() is a good one in situations like this. I will test this again before marking it solved.

Yeah, what IgKh said above...

There is no difference in mechanism, so any difference in behavior you observe may be a coincidence. There is not enough information in the post to determine. I'd check that the SQLite connection is completely closed and discarded before removal of the file; note that even on Linux where it is possible to unlink files with open descriptors doing so to SQLite databases is never safe - the WAL or rollback journal file may lose association which can lead to database corruption,

As for getting the error from the static version, you can call the Win32 API method GetLastError yourself, if you'd like.

On Windows, I am getting an error stating that the process cannot access the file because it is in use by another process.

It is not clear when it happens:
a) When SQLite tries to write to that file
b) When you're trying to delete it

If it is b) - is the file still in use by SQLite?