I have created System DSNs to a MySQL and Oracle database and I have been able to use these DSNs to create linked servers in my SQL Server database and all is working fine.
However, I am trying to create a report in BIDS 2008 / Reporting Services 2008 R2 and I am unable to get these system DSNs. When I try creating a data source, I select Type as ODBC, click Edit, my System DSNs on that same machine aren't displayed.
I will be very grateful for any help. Thanks
Are you using a 64-bit machine? If so, be aware that on a 64-bit machine there are TWO ODBC Data Source Administrators, one for 32-bit and one for 64-bit drivers. If you create a System DSN in either one, it is not visible in the other.
The 64-bit version is usually in C:\Windows\System32\odbcad32.exe
The 32-bit version is usually in C:\Windows\SysWOW64\odbcad32.exe
I'm not sure which version Reporting Services is looking for but try opening both versions up and re-creating your DSN in the one where it's missing (assuming there are both 32-bit and 64-bit drivers for your data source).
Related
I have written an SSIS package and I'm having trouble with connecting to the MySQL server.
Ive tried both .NET connector and ODBC and I've hit issues with both.
The .NET connector has a known issue with dynamic queries and gives an error regarding not finding column P1 (which is a variable).
The recommended route to get past this is to use ODBC to connect. When i use the ODBC connector i get an error regarding memory issues with connecting to MySQL.
I have installed both 64 and 32 bit ODBC MySQL drivers and setup my ODBC connection, but it doesn't fix my issue.
I have tried just entering a connection string, but this leads me back to the memory error.
When reading some online guides it mentions two different Data Sources needing to be setup, one for 32-bit and one for 64 bit, but in Windows 7 I cannot see a 64 bit Data Sources program?
I have also found people mention using a specific mysql.data.dll file but i cannot find this file nor where to put it or reference it.
Read the below Microsoft KB to find the executables location to configure the 32-bit and 64-bit ODBC data sources. You need to configure the appropriate ODBC source so you can view it in BIDS or make the SSIS package run within an SQL Server Agent job.
Microsoft KB 942976
32-bit version of Odbcad32.exe file is in %systemdrive%\Windows\SysWoW64 folder.
64-bit version of Odbcad32.exe file is in %systemdrive%\Windows\System32 folder.
System drive would be the drive where you have installed the operating system.
I have an application written in MS ACCESS 2007 using VBA, connecting to an SQL Server at the back end. Both Access and SQL Server are running locally.
My machine runs Access 2010 and MS SQL Server Express 2008 R2 (both 32-bit, on WinXP) with no problem.
I have another machine, Win7 64-bit, running both Access 2010 and SQL Server 2008 (NOT R2) 64-bit.
When I run the Access application on the 64-bit machine, I have a drop down box to select the SQL Server which holds the various databases. When I select the server, after a few seconds I get an error:
Run-time error '-2147024703 (800700c1)':
Automation error %1 is not a valid Win32 application.
When I select the Debug option, the yellow arrow points to:
Set oServer = New SQLDMO.SQLServer
The next line is:
oServer.Connect ServerName, strSQLUser, strSQLPwd
In the watch list, I can see that ServerName, strSQLUser, and strSQLPwd hold the right values to access the SQL Server. I've tested these in sqlcmd and successfully was able to query tables.
Can anyone please help me out on this one? I'm not sure what to do next.
Seems like you've got registered a 32-bit SQLDMO on your system that is being used for connection to the 64-bit instance. Check your registry / file system for SQLDMO.dll versions and register the correct one.
Also check MSDN "Installing SQL-DMO" because SQLDMO was scheduled for remove after SQL Server 2008 R2:
Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
SQL Server Database Management Objects (SQL-DMO) has been removed from SQL Server 2008 R2 Express and the SQL Server 2008 R2 Feature Pack. SQL-DMO also does not support Database Engine features introduced after SQL Server 2000. We recommend that you modify applications that currently use this feature as soon as possible. If you must support SQL-DMO, install the Backward Compatibility Components from the SQL Server 2008 Feature Pack from the Microsoft Download Center. Do not use SQL-DMO in new development work; use SQL Server Management Objects (SMO) instead. You can obtain the SMO documentation by installing SQL Server 2008 R2 Books Online.
Thanks for this.
I looked to find SQLDMO.DLL 64-bit version, but although using the Backwards Comparability package for x64, installing using the MSI did not do the job.
I had to manually extract the files and place the correct version (which is ~2MB larger than the x86 version as an indication to knowing which one is the x64) and then run 'regsvr32 sqldmo.dll ' in the command line (very important: need to run cmd as Administrator for this to succeed).
After the module has been registered, my Access front end run great.
I'm using Visio 2010 Pro to reverse engineer my database. For some reason the wizard can't see my file dsns (I create them using the wizard) but System DSNs work fine. I'd like to make my DSN files portable so they can be shared with my team.
I've tried running Visio as administrator and have created umpteen file DNSs without success. Is there something I'm missing?
I had the exact same issue and I believe the issue is related to running a 32-bit version of Visio on a 64-bit machine. In my case, I was running a 32-bit version of Visio on a Windows 7 box. I had to go into the 64 bit ODBC dialogue directly (located here: C:\Windows\SysWOW64\odbcad32.exe) and create my connection, and then was able to go back into Visio and successfully connect. I believe what happens otherwise is you default to the 32 bit ODBC dialogue when creating your DSN in Visio, which then fails to show up when you are attempting to select your DSN later in the wizard process. This post touches on some additional detail regarding the 32-bit vs 64-bit nuances: http://robertoschiabel.wordpress.com/2008/02/28/windows-x64-32bit-odbc-vs-64bit-odbc/
Well, this is a bit awkward. I currently have a set of reports on a 32-bit sql server 2005 instance that references an access database on a network location. I'm currently trying to migrate these over to my new reporting services instance (sql server 2008 64-bit), and i've ran into an issue.
Well, i did a google search on the error and got a bunch of stuff saying to compile to use x86 and use 32-bit, etc., but none of it even touch on if i was getting this in rpeorting services.
My question is, is there a way to "fix" this, or some sort of work-around? Perhaps there's another provide i can use to get to the access database?
Any ideas would be much appreciated.
Ran into the exact same problem today, as you alluded to there is no 64-bit Microsoft.Jet.OLEDB.4.0 provider available. This impacts reports that attempt to use Excel and Access datasources on a 64-bit Reporting Services instance. Here is the KB article confirming that no 64-bit Jet driver is available:
http://support.microsoft.com/kb/957570
The solution I found is from this forum post on MSDN:
http://social.msdn.microsoft.com/Forums/en-US/sqlreportingservices/thread/9e999fb4-5a39-41c4-8fd7-46193a223673/
It involves creating an SSIS package that reads the Excel or Access data source, running the SSIS package in 32-bit mode, and using the SSIS package as the report datasource. Not ideal, but it works.
I'm afraid this is the nasty workaround to which we're limited.
I ran across this, which worked in a specific case:
http://danielcai.blogspot.com/2011/02/solution-run-jet-database-engine-on-64.html
From that post:
Microsoft has released a 64-bit compatible Jet database engine last year. The following is the procedure that you may use to fix this issue:
Download Microsoft Access Database Engine 2010 Redistributable (of
course you'll need to choose the right bit for your server), and
install it on your server
Change your connection string in your code or configuration file from
Provider=Microsoft.Jet.OLEDB.4.0;
to
Provider=Microsoft.ACE.OLEDB.12.0;
I usually make applications with the front end in Access 2003 - 2007 and the back-end on SQL Server 2008. When I create an ODBC to link the tables in access I have two choices in the ODBC Data Source Administration page on my Windows XP PC:
Server 2008: SQL Server Native Client 10.0 v.2007.100.2531.00
SQL Server v. 2000.85.1132.00
Which of these should be better and compatible on PCs with just Access 2000?
The native client has support for some additional (more advanced?) features of sql server 2008 (and 2005 I believe).
However, out of the box, you are far more likely to find the standard sql server driver installed on the computer.
Unless you are using some type of installer, or some other software installs this native client driver, then you are best to stick with the default non native driver for maximum compatibility. And, there is just the plain issue that the standard driver is most likely to be already installed on your client side computer.
So, that new native driver not going to be installed by default, and you likely have somewhat better luck with the non native default driver. I had a few issues come up with exporting date columns when using the new native driver (can't recall just right now what the issue was, but there was an issue).
Note that your connection strings are/will be slightly different for the native driver, and if you have some re-link code, that code will fail on computers without the native driver. So, while you have both on your computer, you can't assume this will be the case on other computers. So, you should have special and good reaons to choose/use the new native drivers for 2008/2005, but if not, then use the standard ones.