![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
billroperOn Friday, I finally figured out that the reason that the database connection from the HSF Server installation I had been handed to debug to the Oracle database it was supposed to be sending data to was failing was because we had a 32-bit HSF Server talking to the 64-bit Oracle OLE DB libraries. Actually, to be more accurate, it was not talking to the 64-bit libraries. At all. Which was, once I figured out that the wrong version of the libraries had been installed, not at all surprising.
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...
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...