none
ODBC Driver 13.1 for SQL Server 16 from Windows 7 client RRS feed

  • Question

  • I'm working to get an Access application talking to a SQL-Server 2016 that has Always Encrypted set for a few columns. I've got the ODBC Driver 13.1 running, and everything seems to be working from Access 2010 on Windows 10. But on Windows 7 workstations I'm getting "unable to update" behavior.

    After a bit of research, on https://docs.microsoft.com/en-us/sql/connect/odbc/windows/system-requirements-installation-and-driver-files I came across this:

    Windows 7 ODBC Driver 11 only

    which makes me think I need to upgrade the workstations to make this work.

    Am I reading this right? Even though the ODBC Driver 13.1 for SQL Server installs and seems to mostly work on Windows 7, it's not supported, so that's why I'm having trouble on my Windows 7 workstations?

    Any experienced comments much appreciated.

    Tuesday, February 7, 2017 5:55 PM

Answers

  • I believe the 13 drivers will install on windows 7.

    However the HUGE, MASSIVE IMPORTANT detail here is that you actually need to install the x64 bit .dlls and use the x64 bit installer for Access x32.


    As a general rule you cannot mix and max x32 and x64 bit .dll’s. However the ODBC client installers are for the OS version and NOT the office bit size version.

    WHEN you install the x64 bit client, it ALSO installs the x32 bit .dll’s.

    The x32 bit install will in fact fail with a “strange” message about “Installation of this product failed because it not supported on this operating system”

    However the above means you installing the WRONG version and NOT that the drivers cannot be installed or are not supported.

    So while you can’t mix and match x32 office with x64 bit programs, in this case you MUST install and use the x64 bit installer for the ODBC drivers and that MASSIVE detail about the x64 bit drivers ALSO includes the x32 bit drivers is left out.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Wednesday, February 8, 2017 12:19 AM

All replies

  • My problems on the several Windows 7 workstations I've tried this on may be related to the "SQL Server" driver, also.

    Here are the versions from Windows 7. Notice the "SQL Server" is version 6.x.

    ODBC for Windows 7

    Here's what's on my Windows 10 workstation (where everything seems to be working):

    ODBC Drivers Windows 10

    On my Windows 10 PC it looks like the drivers (especially "SQL Server") are version 10.x. Would getting these drives on my Windows 7 PC make it work? Or are these Windows 10 only drivers?


    Tuesday, February 7, 2017 6:02 PM
  • ODBC driver 13.1 is supported on Windows 7 if the system requirements on the download page for it are correct.

    https://www.microsoft.com/en-us/download/details.aspx?id=53339

    What is not clear is which driver you're actually using on the Windows 7 boxes.  I see that you have several installed but which one are you using when you get the "unable to update" error?  Are you using linked tables with a DSN or are you connecting to your SQL data in some other way?

    -Bruce

    Tuesday, February 7, 2017 9:04 PM
  • I made some changes to the SQL structure that cleared up several tests I was having trouble with -- all of them changing SQL bit columns to not allow nulls and setting all the rows with null in them = 0.

    Then I ran sp_refreshview in SQL for each of the affected Views.

    Then I dropped the linked views from Access, linked them back in again, and now Access can update the data from a Form that's based on the SQL View (that links in as an Access Table) on my Windows 7 PC.


    Tuesday, February 7, 2017 11:55 PM
  • I believe the 13 drivers will install on windows 7.

    However the HUGE, MASSIVE IMPORTANT detail here is that you actually need to install the x64 bit .dlls and use the x64 bit installer for Access x32.


    As a general rule you cannot mix and max x32 and x64 bit .dll’s. However the ODBC client installers are for the OS version and NOT the office bit size version.

    WHEN you install the x64 bit client, it ALSO installs the x32 bit .dll’s.

    The x32 bit install will in fact fail with a “strange” message about “Installation of this product failed because it not supported on this operating system”

    However the above means you installing the WRONG version and NOT that the drivers cannot be installed or are not supported.

    So while you can’t mix and match x32 office with x64 bit programs, in this case you MUST install and use the x64 bit installer for the ODBC drivers and that MASSIVE detail about the x64 bit drivers ALSO includes the x32 bit drivers is left out.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Wednesday, February 8, 2017 12:19 AM
  • The only real difference of using the native 11, or 13 drivers is you have to install such drivers on each workstation. Because of this “hassle” I still right now use the SQL Driver. This is the non-native “legacy” driver, and it works with ease since I don’t have to install any client “11” or “13” drivers on each workstation.

    The MOST common issue is that if your database tables use any of the newer datetime2 formats, then the older legacy drivers will return those columns as strings. And note that the SQL migration wizard by default will choose datetime2 unless you change the defaults during the up-size process.

    In these cases you are best to avoid the newer SQL datetime2 columns, but if you cannot, then you have to install the native 11 or 13 drivers on each workstation and that can be a lot of work.

    So if one “does” have control over the database then it is best to avoid the newer date time types in SQL server if possible, else you have to deploy SQL drivers to each workstation.

    There is "little" reason to adopt the 11 or 13 drivers - about the only real advantage at this point in time is support for the newer date/time columns.

    Regards,
    Albert D. Kallal (Access MVP)
    Edmonton, Alberta Canada

    Wednesday, February 8, 2017 12:26 AM
  • My objective is to get this working with SQL-2016's "Always Encrypted" option on several of the data columns. So I think the ODBC SQL 13.1 driver is the only way to do this. Am I right on this? Or am I making it more difficult than it needs to be?

    I only have about 10 workstations to install this on, so installing drivers on them one time is tolerable.

    Wednesday, February 8, 2017 12:30 AM
  • The new 2016 encryption feature is likely a good reason for the native 13 drivers.

    No big issue about the client stations - it just often "less" work to go with the legacy driver that already installed. (in other words, if you don't have to, then you don't have to !).

    That encryption is a "new" 2016 feature - one I not tested.

    While we had "encrypted" columns in SQL server for a GOOD many years, such columns require T-SQL and a Decrypt('some key') to work in SQL. The new feature you mention does NOT require the keys to be supplied in the T-SQL (it is managed at the driver level - so yes, you likely need native 13 for this to work).

    So that "new" decryption system is rather cool - but one I not tested for use with Access. Assuming their claims that this works at the driver level, then it should work with Access - but some testing is warranted.

    Regards,

    Albert D. Kallal (Access MVP)

    Edmonton, Alberta Canada

    Wednesday, February 8, 2017 1:09 AM
  • The download options confused me a bit, but I assume even though this one looks like it's for amd instead of intel, this is the right one, that contains both the 32bit and 64bit drivers, right?

    amd64

    After installing from the amd64 download, I can create 32bit or 64bit ODBC Data Sources.

    But 32bit Access can only use the 32bit ODBC Data Sources, right? In the table linking dialog from 32bit Access I can only see the 32bit ODBC Data Sources, right?

    Thanks.

    Wednesday, February 8, 2017 12:21 PM
  • 'Using "quotes" around random "words" is "really" annoying and "looks" silly...'
    Thursday, January 17, 2019 1:33 AM