MSS driver versions.

Author: (Iain Sharp)

So, we are currently supporting the same version of our software in many environments. I am now dealing with virtually every sql server version from 2005-2017, including 2008, 2012.  We roll out centralised configuration files, but there are now 3 different versions of the sql server drive relevant to uniface 9.7 (U4.0, u5.0 and U5.1) Which is 'best' (involving least danger AND least hassle for us to maintain the correct ASN settings.)   - Keep everyone on U4.0    - Move all the configs to U5.1 (does this run SQL 2005?)   - Manually visit each machine and change the centralised config to one which matches the sql server version from the PAM. This is fraught with getting it wrong possibilities.    Iain


  1. We have also support for MSS 2008 up to 2016 We had everything on U5.1, but had to change for MSS2008 - 2008R2 back to U5.0 for performance issues we don't have the connection pooling active U5.1 -> SQL ODBC driver U5.0 -> SQL Native driver

    Author: Stijn Courtheyn (
  2. Some background which might explain things and help with decisions.  To be clear, from a support perspective, you should use the driver versions in the PAM with the relevant version of database. Using MS SQL as the example, the change in minor versioning (u5.x), reflects that something has changed in the driver, and its usually that it has been rebuilt with the respective version client libraries.  We would have rebuilt the driver for a reason, usually it is because the current driver did not pass our tests 'as-is' against the newer release of the database. If it did not pass our tests, this means something could be different in your app. In the case of MS SQL, I think I am correct in remembering that the u4.0 driver, built on MS SQL 2005, is the exception, where it also verified successfully on MS SQL 2008.  A change for the major version number, ux.0 usually reflects that there has been a significant functionality change, for example pagination added.  There have been exceptions to the numbering scheme, but in recent years, this is how we have been doing it. 

    Author: Adrian Gosbell (
  3. Thanks for clearing that out. But from a deployment point of view, reality is a lot more complex. Especially since there is cross-version compatibility between MSS client and server versions. Since the Uniface driver version reflects the binaries against which it's compiled, i would think it's the Client Versions, not the Server versions. Therefore I would think that the Product Availability Matrix should reflect the Clients software version and not the Server Version. So MSS U4.0 should refer to "SQL Server Native Client" or "SQL Server Native Client 10.0" and not "MS SQL Server 2008" We are dealing with thousands of different workstations, not every OS version is supported for every Driver version. As long as we use a SQL Client driver that's compatible with the DB Server Version this should be OK since Microsoft claims compatibility and supports it.

    Author: wimmme (
  4. Per SQL Server version Microsoft introduces new, changed or deprecated functionality , datatypes. In the past for example the MAX datatypes have been introduced and TEXT,NTEXT,IMAGE are deprecated. Another example is changed locking behavior for cursors of SQL Server 2005 compared to SQL Server 2000 The Uniface driver version reflects the binaries against which it is compiled. However the Uniface driver will use functionality and datatypes from the corresponding SQL Server version. So one has to be careful with mixed SQL client and server versions. We do not verify all these mixed combinations.

    Author: PBeugel (