If you have an ability to force web-style updates on the client apps (which a tool like Conveyor supports, see my other posts or profile), then all you need is a database that supports many connections. You can then atomically upgrade all the clients by e.g. writing a version number to a db table that's checked as part of each transaction, if the version doesn't match the app proceeds to upgrade itself before continuing (unless it's marked as a soft update, i.e. not worth interrupting the user for). The versioning issues aren't much different to the ones you face once you decide to have multiple web servers and rolling upgrades.
I'm happy for you if that's working out in your enterprise. It was not our experience in the time frame we're talking about (VB was sunset over 20 years ago), and frankly it was not our experience 5 years ago - when we were running skads of applications on Citrix servers so we could have absolute control over the "client" runtime environment, and have the actual on-the-glass experience be thin client.
IIRC back in the day, Windows could not replace a file if the file was open by any process. So an application could not update itself, without doing something like launching a separate "updater" and then exiting.
Another thing people tried was putting the VB app on a network share so it wasn't installed on each machine, but I think all the ODBC and other config still had to be local on each client.
