Knut said (...) I've looked though the documentation - and I cannot find any matrix / comparisons between the different driver versions - (...)

..that would mean going through various older PAM's to find out which driver belongs to which Uniface version and subsequently dig up the (sometimes offline) documentation of that particular Uniface version, to look up the driver functionality, as there has never been (AFAIK) any direct comparison documents on various driver versions like U63, U70, U71, U72. Knut said

(...) and we have no way of converting our data from long to clob/blob (or the other way around).(...)

This migration seems a pretty common (unavoidable) thing in the Oracle world. This is what Oracle says about it. Please note that 'he other way around' (Converting LOB datatypes back to LONG datatypes) is not supported according to this page.

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. 

Hi Knut, with such massive amount of data everything it's same time a problem and an opportunity! In your context moving away from LONG* cannot be done in a single shot. Are those prod databases all daily alive or can somehow be splitted to manage them by chunks (application models?) ? Gianni

Hi Gianni, They're all realtime... To add further complications and complexity; We've got old COBOL programs, new .NET programs and several hundred stored procedures, all making use of LONG* in order to access these databases.... Knut