A few points here.. Looking at some of the statements from Oracle, they view LONG as depreciated, and advise not to use it, and for customers to plan to move to alternatives. But apparently they still make use it themselves..But the statement from Oracle is there. In regards to the Uniface connectors, our policy is that the major version number changes when there are source code changes to the driver, these could be to add functionality (pagination or unicode for example) or to support a newer version. (I don't recall the last time we've had to do this). An example of a major version change would be u6 to u7. Minor version number changes usually reflect that we have rebuild the driver with newer client libraries, usually released when the database vendor releases a new database server. Functionality wise, its the same as the previous driver, just the client libraries are different (newer). There have been exceptions to this in the past, I assume to speed up delivery. Our Oracle connector is the only one of our 'mainstream connectors', which has not been rebuilt to use our 'UDT' architecture, where we try to have as much 'common functionality' as possible in one layer, and keep the database specific code in a separate layer. It makes changes more efficient (we found this when we did the SQL/print and the pagination enhancements). From a product management perspective, I would really like to rebuild the Oracle driver to follow the UDT architecture. If we did, I'd be in favor or removing all of the backwards compatibility stuff and making it as 'clean' as possible. (the number of USYS$ORA_PARAMS settings gives an indication of how complicated the driver is). We would have to maintain the old driver for 'compatibility purposes'. Note this is something I'd like to do, it's not in the roadmap and I don't see it coming up anytime soon.
Author: Adrian Gosbell (
adrian.gosbell@synapse-i.jp)