I know that this is problem caused by very bad design by MS. But maybe someone already found a workaround and would share it here.
I need to call the same DSN sometimes from a 32-Bit application, and sometimes from a 64-Bit application. So I need a DSN with the same name once created with the 32-Bit ODBCAD32.exe and once with the 64-Bit ODBCAD32.exe. One therefore has to reference the 32-Bit version of FBClient.dll and the other references the 64-Bit version. No problem for System DSNs. The different settings do not mess with each other. For User-DSNs though, you must decide whether a DSN is either 32- or 64-Bit because no matter which version of ODBCAD32.exe you are using to create/manage the DSNs, they will both be stored in the very same registry key, which basically means that any setting in either ODBCAD32.exe will overwrite the other, and therefore the last selected version of FBClient.dll will win. Sounds like there is no solution for this, and I can't even start to imagine which idiot in Redmond let that pass. But, anyway, did anybody of you stumble across some workaround, maybe involving some system hacks? I frankly do not even know where all the places are where some 3rd party tool is making a call to a User-DSN. Users even can create their own Excel/LibreOffice/CrystalReport connections based on an existing User-DSN. thanks, André ------------------------------------------------------------------------------ Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester Wave(TM): Endpoint Security, Q1 2013 and "remains a good choice" in the endpoint security space. For insight on selecting the right partner to tackle endpoint security challenges, access the full report. http://p.sf.net/sfu/symantec-dev2dev _______________________________________________ Firebird-odbc-devel mailing list Firebird-odbc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/firebird-odbc-devel
