I sent an e-mail explaining this to everyone.
And I realized today that on Monday, they would install the correct drivers. And then, I would never be able to sort out exactly why the Admin Client was saying that the database operation succeeded when it had clearly failed.
So I spent some time today sorting it out. And I discovered that one of the functions on the Server that was checking to see if the previous transaction had succeeded would trap all exceptions and return a SUCCESS! result.
Because, of course, catching an exception clearly means that we're all fine here.
So I changed the method to return a standard failure code.
And then I discovered that the Admin Client would lose its connection to the Server.
A bit more investigation showed that most simple failure codes would cause this to happen, because there was a test that said "If the failure code is less than this enumerated value, kill that connection." Right. Apparently, this was because whoever wrote this expected a well-behaved function to return one of the enumerated error codes.
Ok. So I found an enumerated error code that reasonably matched the failure (most easily translated into English as "Database? What database? I don't see any database here..."), passed it back when catching an exception, and now the connection doesn't drop on failure of this method.
This was way too much work to be doing on Sunday...