André Knappstein
2013-03-07 11:15:52 UTC
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é
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é