reporting services - SSRS Issues with 32bit and 64bit ODBC drivers -


the ultimate goal users able run report looks pretty , grabs current information our database. we'd use sql report builder since we're using other reports. database cisco uccx , we're accessing odbc connection our reporting services sql server 2008 r2.

we've setup system odbc connections both 64bit , 32bit drivers. when trying access connections though, we're receiving errors.

using 32bit driver, try create data source in ssrs use report builder , receive error:

"error [im014] [microsoft][odbc driver manager] specified dsn contains architecture mismatch between driver , application"

using 64bit driver, can create , test odbc connection data source, when attempt create dataset in report builder, error:

error [im002] [microsoft][odbc driver manager] data source name not found , no default driver specified

error received using 64bit driver odbc connection

you may hitting old recurring issue minor corruption in windows registry.

the corruption takes form of entries containing 4-character string —

@=""   

these entries aren't visible anywhere except registry export files — registry editor ignores them — can lead number of undesired behaviors, including error report.

note: on 64-bit windows machine, there naturally complications tied 32-bit registry. this microsoft kb article may sufficient through these.

i suggest use 64-bit registry editor (%systemroot%\system32\regedit) export following branches (where these problematic entries tend found) —

hkey_local_machine\software\odbc hkey_current_user\software\odbc hkey_local_machine\software\wow6432node\odbc hkey_current_user\software\wow6432node\odbc 

edit these files in text editor (notepad or wordpad fine), , delete lines consist of 4-character string, above. then, delete registry tree segment(s) exported, , import edited files — thereby restoring tree segment(s), minus corruption.

it won't hurt repeat above process 32-bit registry editor (%systemroot%\syswow64\regedit), you've described issue, don't think you'll find @="" in 32-bit export.


Comments