General database changes related storing handles
The database code base no longer holds on to OS memory for storage of various handles related to the database interfaces calls.
Reason for change
When the database code was adapted to the new 32bit/64bit VM and its new memory management protocol, we decided to allocate and manage the memory used for the various database handles directly. We decided to hold on to this memory and reference the handles using the pointerAt: protocol. Upon reflection, we feel these particular changes were a bit confusing and awkward to work with. While the database code is still allocating and managing its OS memory usage, we have decided to only hold on to the handle data, not the OS memory containing the handle.
Action required
If you are simply a consumer of the database code and have not modified or extend the database layer with your own enhancements, then you will not need to do anything.
If you did extend or modify the base database you may need to make some adjustments. A typical reference to a statement handle (stmthp), error handle pointer (errhp), or environment handle (envhp) might look something like this in 9.1:
•self stmthp pointerAt: 0
•self dbConnection errhp pointerAt: 0
•self databaseManager henv pointerAt: 0
Note that there are other handle objects to lookout for.
In 9.2, the database code is no longer holding on the physical OS memory, so the handles are just integer values. In 9.2, you would reference the these handles like this:
•self stmthp
•self dbConnection errhp
•self databaseManager henv
If you miss updating one these types of handle pointers, you will experience errors indicating the Integer does not understand pointerAt: .
Last modified date: 11/15/2019