We had to implement changes to our password policies. To centralize business rules, we coded the specifics in one password verify function. This was painful to test because we have many applications that connect to the database using different technologies.
I found that those applications which used OLE DB were able to respond to errors intelligently. We threw different errors when bad passwords were chosen. This was a breeze to catch using OLE DB.
For most of the generic errors we were able to handle the situation with applications using Pro*C. However some errors contained larger error text. There were multiple ORA error numbers embedded in the text. With Pro*C, we were getting the from the SQLCA (SQL Communications Area). But the error text in this structure is limited to 70 characters. There were scenarios where we needed access to more text.
In the end we implemented a hack whereby the Pro*C code duplicated the password verification logic so we were not stuck needing more than 70 characters of error text. I seriously hope we can redesign this hack in the next go around. Perhaps we shall port all the Pro*C access to use OLE DB. Or maybe we can dig deeper to find a way to resolve this in Pro*C.
Reproducing a Race Condition
-
We have a job at work that runs every Wednesday night. All of a sudden, it
aborted the last 2 weeks. This caused some critical data to be late. The
main ...