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

The ultimate goal is for users to be able to run a report that looks pretty and grabs current information from our database. We'd like to use SQL Report Builder since we're already using it for other reports. The database is Cisco UCCX and we're accessing it with an ODBC connection from our reporting services SQL Server 2008 R2.
We've successfully setup System ODBC connections with both 64bit and 32bit drivers. When trying to access the connections though, we're receiving errors.
Using the 32bit driver, we try to create a Data Source in SSRS for use by Report Builder and receive the error:
"ERROR [IM014] [Microsoft][ODBC Driver Manager] The specified DSN contains an architecture mismatch between the Driver and Application"
Using the 64bit driver, we can successfully create and test the ODBC connection as a Data Source, but then when we attempt to create a Dataset with it in Report Builder, we get this error:
ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified
Error received using the 64bit driver for ODBC connection

I ran into this recently. You need to have the same name for both 32 and 64bit DSNs. It's annoying because SSRS can run 64bit, but reportbuilder only exists in 32bit. So parts of reportbuilder seem to work (like running queries), but some don't (like refreshing query fields). Just have a DSN for both 32bit and 64bit, then make sure they're both the same name and the problems should stop.

You may be hitting an old but recurring issue with minor corruption in the Windows Registry.
The corruption takes the form of entries containing this 4-character string —
#=""
These entries aren't visible anywhere except Registry export files — the Registry Editor ignores them completely — but they can lead to a number of undesired behaviors, including the error you report.
NOTE: On your 64-bit Windows machine, there are naturally some complications tied to the 32-bit Registry. This Microsoft KB article may be sufficient to get you through these.
I suggest that you use the 64-bit Registry Editor (%systemroot%\system32\regedit) to export the following branches (where these problematic entries tend to be 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 any text editor (Notepad or Wordpad are generally fine), and delete all lines which consist of that 4-character string, above. Then, delete the Registry tree segment(s) you exported, and import from the edited files — thereby restoring the tree segment(s), minus the corruption.
It won't hurt to repeat the above process with the 32-bit Registry Editor (%systemroot%\syswow64\regedit), but as you've described the issue, I don't think you'll find any #="" in the 32-bit export.

Related

Where are ODBC Machine DSN settings stored in Windows?

In my Access database, I reference the DSN, "mydatasourcename" to connect to an online MySQL database. It is a machine DSN. Somehow through the course of editing my config files, a phantom DSN was created. This DSN is now out of date and I need to update it with the new hostname (after having migrated the MySQL Server). But the config file is nowhere to be found. It does not show up in either 32-bit or 64-bit "ODBC Data Sources" forms. I have searched "mydatasourcename" in the Registry Editor and it is not there either. Mysteriously, when I open an Access linked table referencing "mydatasourcename" it opens a MySQL ODBC Connector dialogue with the old connection information in it. How is it doing this? Where is it getting the connection string information? To answer this question, I am requesting a list of the places the ODBC driver looks for configuration files and how to access them so I can delete the old configuration file. I am using MySQL ODBC Connector 8.0.16. Thank you.
EDIT: The connection string found in my linked table is definitely looking outside of Access for connection info based on the fact that is referencing a DSN. The connection string in one of my linked tables is the following: "ODBC;DSN=mydatasourcename;;TABLE=qrychemigationapplications_materialsrequired1"
On Windows, ODBC DSN information is stored in the Windows Registry. System DSNs can be found in the registry keys
DSNs for 64-bit drivers: HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI
DSNs for 32-bit drivers: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\ODBC\ODBC.INI
and User DSNs can be found in
HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI
If a DSN does not appear in the ODBC Administrator (odbcad32.exe) it might be because the DSN name is not included in the list of DSNs in the corresponding subkey
...\ODBC.INI\ODBC Data Sources
Paths to odbcad32.exe:
x86:
%windir%\syswow64\odbcad32.exe
x64:
%windir%\system32\odbcad32.exe
I was able to find the "Machine Data Sources" that Microsoft Access creates in the Windows Registry Here:
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\ODBC\ODBC.INI\ODBC
Data Sources
The "Machine Data Sources" that are in this part of the registry, seem to be accessible only via MS Access. If you look for them instead using the standard Windows ODBC Data Source Administrator "widgets" (32 or 64 bit), you just don't see the "Access Created" Machine Data Sources for some reason. If anyone can tell us why, that would be great!
What's more frustrating, is that at least with the latest Microsoft Access Office 365 version, you can only create NEW Machine Data Sources. You can't delete or edit existing "Machine Data Sources".
That being said, if you avoid creating the "Machine Data Sources" using Microsoft Access itself, and instead use the standard 64 Bit Windows ODBC Data Source Administrator "widget", then for whatever reason Access will see those that you create in this way.
So having the issue that you're describing, just seems to be the result of some weird design that Microsoft has implemented specifically in regard to Microsoft Access ODBC connections, for a reason that escapes me.
Hope this helps!
Below is an alternative to accessing the Windows Registry:
Control Panel
Administrative Tools
ODBC Data Sources (32-bit or 64-bit)
Click the tab for: User DSN, System DSN, or File DSN
Click the name of the Data Source
Click Configure... if you would like to view or modify the details of the data source

Error accessing Oracle view through SSIS

I'm getting errors while trying to access an Oracle view through an SSIS package. First, since, I'm running 64-bit windows, I installed the 64-bit Oracle 12c Client. But when I tested the connection I got this error:
Test connection failed because of an error in initializing provider. Attempt to load Oracle client libraries threw BadImageFormatException. This problem will occur when running in 64 bit mode with the 32 bit Oracle client components installed.
Then I tried installing the 32-bit Oracle 12c Client but got another, different error.
Test connection failed because of an error in initializing provider. ORA-12154: TNS:could not resolve the connect identifier specified
Lastly I tried installing both clients together but the last error persisted. Not sure what's going on here...
The first error comes from the fact that Visual studio is 32 bit and it's trying to use 32 bit drivers by default. You can change the runtime settings like this: https://stackoverflow.com/a/28235255/5605866
The second error might refer to tnsnames.ora file not having all the settings correctly, like in here: https://stackoverflow.com/a/40399744/5605866

Error code 0x80004005 when executing package as a scheduled job

The error message is:
POSTGRES dm_genders_d failed validation and returned error code
0x80004005.
I've seen several references to this almost assuredly being a permissions issue, which sounds right to me, but I have been completely unable to identify the relevant permissions.
The Postgres connection is using ODBC. The package is moving data from PostgreSQL to SQL Server. Currently both 32bit and 64bit drivers exist, but I haven't seen how to choose between them.
I have made all of the recommended changes to 32 bit for the job.
We are using Windows Authentication.
I've set up a proxy to execute the job as my user.
None of this has alleviated this error.
UPDATE: Yes, the 32 bit data source has been defined, and it is being used.
I had this error and I could solve it by Add ODBC connection in the "system DSN" instead of "User DSN" tab.
Start > ODBC Data Sources
Also I ran package with 32-bit runtime
for this: right click on your job in SQL Server Agent > properties > steps > edit
in the window that appear (Job Step Properties) you can set 32-bit runtime. (below picture)

Mysql table on Excel sheet?

I am using Windows7 and Microsoft office 2010 and mysql5. I want to connect Microsoft excel with my database mysql. I have installed all the drivers. I have created a data source as well. I am going step-by-step to connect, but at the end when i click on test connections, I receive this error message
Test connection failed because of error in intializing provider unspecified error.
You probably are not using the right ODBC driver.
Please check if you downloaded the one that matches your MySQL database. (not only version number, but especially if it is a 32-bit server or a 64-bit server).

MySQL ODBC Issue: Data source name not found and no default driver specified

I'm currently trying to run a classic ASP application which I've been given source code for. I want to set up on my 64bit Windows 7 dev machine and am having trouble with an ODBC based data connection to a MySQL instance.
I'm seeing the error:
Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Data source name not found
and no default driver specified
/includes/<File Name>.asp, line 100
What I've tried:
The connection is DSN-less.
The application is running under IIS app pool with local system permissions. w3wp.exe can be seen running under NT AUTHORITY/SYSTEM in process monitor.
The application is running under IIS app pool with 32 bit applications allowed to run.
Have tried with Connector/ODBC 5.1.10 64 bit version only installed from http://dev.mysql.com (At this point no driver was listed under C:\Windows\SysWOW64\odbcad32.exe but was under C:\Windows\system32\odbcad32.exe)
Have tried with Connector/ODBC 5.1.10 32 bit version only installed from http://dev.mysql.com (At this point no driver was listed under C:\Windows\system32\odbcad32.exe but was under C:\Windows\SysWOW64\odbcad32.exe)
Have tried with Connector/ODBC 5.1.10 32 bit and 64 bit versions installed.
Verified driver name is not misspelled. Along with other checks from here http://support.microsoft.com/kb/306345.
Driver={MySQL ODBC 5.1 Driver};Server=localhost;Database=DBName;User=root;Password=Password;Option=3
Additional Information:
I'm monitoring in process monitor, and the two results are:
PATH NOT FOUND (Looking for .asp/web.config which seems odd.
BUFFER OVERFLOW
Both entries show:
User: NT AUTHORITY\SYSTEM
Process:
C:\Windows\SysWOW64\inetsrv\w3wp.exe
C:\Windows\SysWOW64\odbcint.dll
I'm stumped can any one make a suggestion on how I get this running in the context I have described?
Solved the problem now. Recording here in case this of use to others.
The issue was much simpler than it first appeared. The problem was that the application used a mixture of named and unnamed datasources (DSN / DSN-Less).
It was not apparent to me that any named connections were used until I set up the application for debugging in Visual studio. Here is a rough guide to debugging the application in visual studio (Except I used HTTP based website, rather than file system):
http://www.codeproject.com/Articles/28792/Debugging-Classic-ASP-VBScript-in-Visual-Studio-20
Following creating the required DSN, there were some further exceptions being thrown regarding default values in database columns. This was due to a MySQL setting that can be changed in the my.ini file.
http://bugs.mysql.com/bug.php?id=14306
C:\Program Files (x86)\MySQL\MySQL Server 5.5\my.ini
# Set the SQL mode to strict
# sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
sql-mode=""
I found this to work from Windows to MySQL as a DSN-less connection. The trick was to ELIMINATE the port spec at the end of the server address.
"DRIVER={MySQL ODBC 5.3 UNICODE Driver}; Server=**;Database=**;User=**;Password=**; OPTION=3"
Note: Server string is the internet address of the server, BUT NO PORT
SPECIFIED - ie, NO ":3306" on the end