It's not that it isn't possible though... It's only a problem if you have multiple connections that wish to write - a very specific case that no normal program really allows, especially not Excel. Your use-case seems like it would easily allow closing a DB from the single writing thread (especially if you do the file-per-recorder type scenario) at which point it can easily be renamed/moved without loss to file-data or integrity. What still needs to be addressed then is the reader connections continuity, if only for the purpose of making said readers understand that the data they are looking at now is either for a different filename (*nix) or the file handle is now unbound (Windows), assuming they do not already have machinery to deal with this. I've done this rather successfully with a simple token file. The moment it appears (with the same name as the open file, plus some marker) then a reader knows to reset it's connection to whatever is in the token. Many more things can be communicated this way, but the need is typically only to flag change to an unconnected system interested in the file. It can also be a setting in the DB file, but the problem is that the DB itself may have moved by the time the reader checks, and at least on some OSes that is a problem.