Post reply

Data Flow Task Error: The version of ODBC Source is not compatible with this version of the DataFlow

  • October 12, 2017 at 2:07 pm

    #1963473

    wh39727 - Thursday, October 12, 2017 11:55 AM

    Has anyone figured this out?  I have a package that works locally, and on 1 production server, but on another i'm getting the same "The version of ODBC File Source, clsid {xxx} is not compatible with this version of the Data Flow" error on a 2nd production server.  Target Version is SQL Server 2016, 32-Bit mode in Visual Studio and when executing from SSISDB on the new server.  Same IBMi ODBC driver is installed on both servers.  Same exact package, same exacts DSN's.  I'm really out of ideas, and help would be great.

    Make sure you used the correct program to create the DSN.   Odbcad32.exe is the ONLY correct way to create a 32-bit DSN for an ODBC connection.   If you open that program on the problem server and don't see your DSN, that could be the problem.    If you do see it, then you can always delete it and re-create it.   I would suggest writing down the details first though.   And remember that the 32 bit program will NOT see any 64-bit ODBC drivers.

    Steve (aka sgmunson) 🙂 🙂 🙂
    Rent Servers for Income (picks and shovels strategy)

  • October 13, 2017 at 1:42 am

    #1963506

    sgmunson - Thursday, October 12, 2017 2:07 PM

    Make sure you used the correct program to create the DSN.   Odbcad32.exe is the ONLY correct way to create a 32-bit DSN for an ODBC connection.  

    Actually on a 64-bit machines the program name is the same for both 32-bit and 64-bit, it is the location that matters
    C:\Windows\System32\odbcad32.exe for 64-bit sources
    C:\Windows\SysWOW64\odbcad32.exe for 32-bit sources
    and note that 64-bit sources will show in the 32-bit admin as 64-bit  although you cannot alter it
    and vice versa for 32-bit

    Far away is close at hand in the images of elsewhere.
    Anon.

  • November 17, 2017 at 12:50 pm

    #1968595

    we had the same issue and figured that out..using ADO.NET Connection instead of ODBC connection!

Viewing 3 posts - 16 through 17 (of 17 total)

You must be logged in to reply to this topic. Login to reply