Today, we upgraded stamps.com software to version 17.5. This build requires that ODBC drivers be 64bit. I didn't think that was a problem. System is 64bit, and downloaded the latest MySQL ODBC 64Bit version 8.0.22. ODBC Data Source Administrator loads up, and I can access it. I create the datas ource (tested) but when I try to assign it via Stamps.com I get the error...
"Unable to connect to the selected data source. Check if you need to add a Username and Password"
Odd. Again, I can test connection via ODBC Data Source Administrator. It selects the proper database, etc. The driver is MySQL ODBC 8.0 ANSI Driver (Version 8.00.22.00).
If I try to "Create a new data source" via Stamps.com. Click 'Other/Advanced (SQL,etc)' and click 'Add', I do not see any MySQL drivers anywhere the options.
I've completely uninstalled re-installed 8.0.22 multiple times.
ADDITIONAL INFO
If I don't try to create a new DSN through Stamps.com but rather select an existing one, but click 'configure'. I get the following errors.
"The setup routines for the MySQL ODBC 8.0 ANSI Driver ODBC driver could not be found. Please reinstall the driver."
Followed by..
"---------------------------
Driver's ConfigDSN, ConfigDriver, or ConfigTranslator failed
---------------------------
Errors Found:
The specified DSN contains an architecture mismatch between the Driver and Application"
So it seems like the MySQL ODBC driver is still 32 bit? I clearly installed 64 bit, and the system is 64 bit, so not sure. It's possible the original ODBC driver was 32 bit from a year ago, but like I mentioned, I have removed those .dll via uninstall.
ADDITIONAL INFO 2
I'm wondering if I'm chasing the wrong 32 bit application. Under ODBC Data Source Administrator, in the About tab,
For About the ODBC core components..
Administrator C:\Windows\system32\odbccp32.dll
Control Panel Startup C:\Windows\system32\odbcad32.exe
Cursor Library C:\Windows\system32\odbccr32.dll
Driver Manager C:\Windows\system32\odbc32.dll
Localized Resource DLL C:\Windows\system32\odbcint.dll
Unicode Cursor Library C:\Windows\system32\odbccu32.dll
So it looks like the 'core' for ODBC is 32 bit? Looking into how to update these for 64bit. Hmmm... based on my initial research, those .dll/.exe are 64bit since they're in system32 and not in sysWOW64. Seems counter intuitive?
Any suggestions?
After contacting support, they informed me that ODBC is not supported with 17.5. So not sure - why I needed to upgrade to 64bit, and why it states that my ODBC drivers need to be 64bit, since it's not compatible.
Here is what needs to be done. Download Stamps clean tool:
https://support.stamps.com/outgoing/clean.exe
Then run key tool to remove any registry values:
https://support.stamps.com/outgoing/key.exe
Then finally, you need to install version 17.4
http://support.stamps.com/outgoing/stamps174.exe
Roll back to the 32bit ODBC drivers.
After this fiasco, we've implemented better protocols. Basically secondary machine with Stamps.com running on it and will test future updates there before rolling out to our primary production machine.
We are in the same boat.... after updating to the Stamps.com version 17.5 we have been unable to get our ODBC MySQL server connection working.
We have tried all combinations of older vs new 64 bit MySQL drivers. We have tried installing the 32-bit version of Stamps 17.5. It actually allows us to configure the connection and select the correct tables and columns we want, but when we trigger a lookup we get an error saying 64bit drivers are required.
Same error on 32-bit Stamps.com vs 64-bit Stamps.com.
We are contacting stamps.com support now and I will update this when/if we find anything additional.
Is there a solution then for this? We were actually using for the past 12 years the old ActiveX solution - but you HAD to use MS-Explorer. So we were exploring using stamps.com ORDERS solution with MySQL ODBC. Tried both the 32-bit stamps.com app (with the 32bit ODBC drivers), and the 64-bit stamps.com (with the 64bit ODBC drivers). The 32-bit at least allow you to complete the field mapping - which tells me it was connected to the database to be able to read the schema. But when you go to actually IMPORT anything, you get the "...you'll need to install the latest 64-bit ODBC drivers..." which I have already tried.
If you download and use the 17.4 version (as suggested above), what happens when you MUST upgrade stamps.com (which does happen about once every 2 years when the USPS changes some fundamental stuff).
Any solutions anyone? We really want off our ActiveX/PDK (12 year old) solution.
Just ran into the same issue this week, albeit with the MS SQL drivers. Doesn't matter whether I install the 64bit or 32bit Stamps.com software (when the site will download the 32bit version at all... it doesn't for me at the moment, only 64bit). Either way, I get the message saying I need to install the 64bit ODBC drivers. And clicking "More info" just takes me to the home Help page, not to a related article. The article detailing 64bit ODBC is pretty useless since it just says you need to install the drivers, but you can view it here: https://stamps.custhelp.com/app/answers/detail/a_id/7244/kw/64-bit%20ODBC/related/1
I called support, and they said it's a known issue but that there's no workaround currently.
UPDATE 2/17/2021
I just talked to Tier 2 support, and there's a new version out the resolves the ODBC error. The download page still says 17.7, but it's actually 17.7.1. Installing it resolved the error for me and I am now able to import orders via ODBC. (I installed the 32-bit version at the recommendation of the support tech I spoke with, I have not tried with the 64-bit version.)
Also, the 32-bit download is working again.
Related
We've got some MS Access 2007 apps here. I'm responsible for one. Normally, it never gives any problems. I haven't heard from the users of this app for over a year, until today. It was written years ago by someone (I don't know who) that is long gone, with little documentation. We're in the process of replacing all of our Windows 7 machines with Windows 10 machines. At first I thought that was the issue. However, one of my colleagues, who is responsible for a number of Access 2007 apps, said that his users are able to use their Access apps with no problem.
Looking back at the user's error, it says simply, "ODBC - call failed". No error number; just that. So, my next thought was maybe there was a missing DSN on the new Windows 10 machine. However, I asked the PC tech to check one of the working Windows 7 machines. He told me there were no DSN's in them. I'm not an Access developer, so I asked my colleague, who does do Access development, what he could discover. He found that the tables are all linked tables from a SQL Server database. Looking at what he was referring to (now that I know where to look) I saw what he meant. The connection to each of those tables uses trusted connections. They're all pointing to the correct SQL database server. That server is there. When I got into SSMS I could easily see data in the tables.
So, what could be causing that error to occur, especially since it doesn't look like it needs a DSN to make a connection to the SQL db?
I presume your Windows 10 is 64-bit.
And probably your Access is 32-bit.
Its important to know!
If my assumptions are correct, you need to use the 32-bit version of ODBC admin to setup the DSN.
The 32-bit version is 'C:\Windows\SysWOW64\odbc32.exe'
The 64-bit version is 'C:\Windows\System32\odbc32.exe'
32-bit Access will look for a DSN setup using the 32-bit version of ODBC admin, even on a 64-bit OS. If you setup the DSN with the 64-bit version of ODBC admin, then a 32-bit Access will not see it!
Go back on the Windows 7 PC, and check exactly how the DSN is setup.
Is it a System, User, or File DSN?
Which drivers are installed for SQL Server?
(There are various different ODBC clients available for SQL Server.)
Replicate this DSN configuration when you create the DSN on Windows 10.
It sounds like you using the 'SQL Server Native Client' on Windows 7,
so make sure to install that on Windows 10.
See: Installing SQL Server Native Client
I'm sure some will say this questions is off topic, but it is truly about programming since I wrote this program and I need to get it working on Windows 10.
I wrote an application in VB.Net and compiled it for "AnyCPU". So it would work in both 32 bit and 64 bit environments. The program communicates with a MySQL database so I load both the 32 bit ODBC drivers and the 64 bit ODBC drivers during the installation. However, one piece of the program uses Crystal Reports for outputting a report. The piece of Crystal I'm using only runs in the 32 bit work space.
The MySQL database installed is 64 bit due to the 64 bit OS.
Everything works harmoniously in Windows_7 (64 bit), but the same configuration does not work in Windows_10 (64 bit). In Windows 10 when the user tries to run the Crystal program to view a report, MySQL throws an error that it can't find the ODBC driver in
"C:\Program Files(x86)\MYSQL\Connector ODBC 5.3\myodbc5a.dll"
Of course the driver is there, but this error is usually due to the wrong bit version of the driver being installed.
The 64 bit version is installed in
"C:\Program Files\MYSQL\Connector ODBC 5.3\myodbc5a.dll"
Is this a Windows 10 issue or something else? How can I get MySQL to use the correct driver location?
I'm not sure if this will help anyone else or not, but basically I went back to ensure that the correct versions of the ODBC drivers were installed in their correct locations. So I uninstalled both versions of the ODBC drivers and tried to reinstall them. In doing this, I saw that the MySQL installer would only let me install one bit version of the driver but not both. My program installs both drivers from the command line in silent mode. But when duplicating my installation method, I noticed that the 32 bit drivers were not being installed correctly when run from the script. But since it installs in silent mode, I never noticed. All of the 32 bit driver dlls were there, including the one shown in the error message, however it was missing 2 dlls that did not get installed properly during the silent installation.
So using the MySQL installer, I tried to install both bit versions of the drivers but as I mentioned above it wouldn't let me. If I installed one version then went back and tried the other version it complained that both versions were already installed. So I had to trick it by installing one version then renaming the folder and then uninstalling it and installing the other version. Once the second version was installed, I went back and renamed the original version's folder back to its original name. That way both bit versions were in thier proper place. However, looking at the installer, it showed that only one version was installed (the one I installed last).
I'm still not sure why my silent installation failed. The error was reminiscent of the error you get when the C++ redistributable needs to be installed, but I tried this and it did not solve the problem. So my immediate problem has been resolved. If I figure out my installation issue, I'll come back and update this answer.
I have a SQL Server job that runs monthly that runs in server. Job is using an SSIS package and is supposed to extract the data from database and and create an Excel sheet and copy the data into Excel 2003.
I actually got around 140,000 rows from the database due to truncation issue in Excel 2003 (Excel supports 64,000 rows). So I modified the config file to support 2007 Excel format.
"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=" + #[User::FullPath] + ";Extended Properties=\"Excel 12.0;HDR=YES\"
But when I try to execute the job, it fails showing error message:
"The requested OLE DB provider Microsoft.ACE.OLEDB.12.0 is not registered"
Summarized: INSTALL 32 bit version of Microsoft Access Database Engine 2010 Redistributable. Uninstall 64 bit version if previously installed. http://www.microsoft.com/en-us/download/details.aspx?id=13255
The Excel connection manager is trying to use the ACE OLE DB provider in order to access the Excel file when the version is above 2007 (xlsx).
Although your box is 64-bit, you’re using SQL Server Data Tools, which is a 32-bit application. There is no 64-bit version for SSDT. When you design your package within SSDT, you’re using a 32-bit process, which can only use 32-bit providers. When you try to choose the table in the Excel file, the connection manager needs to access the 32-bit version of the ACE OLE DB provider, but this provider is not registered on your machine, only the 64-bit version is installed.
You should download the 32-bit version of the “Microsoft Access Database Engine 2010 Redistributable”. When you try to install it, you might get an error message.
You should first uninstall only the 64-bit version of the “Microsoft Access Database Engine 2010 Redistributable”, which you probably installed previously. The 64-bit version and the 32-bit version can’t live together on the same host, so you’ll have to uninstall (through “Program and Features”) and install the other one if you wish to switch between them.
Once you finish uninstalling the 64-bit version and installing the 32-bit version of the provider, the problem is solved, and you can finally choose the table within the Excel file. The Excel connection manager is now able to use the ACE OLE DB provider (32-bit version) in order to access the Excel file.
There is a alter way. Open the excel file in Microsoft office Excel, and save it as "Excel 97-2003 Workbook". Then, use the new saved excel file in your file connection.
Another option is to run the package in 32 bit mode. Click on the solution => properties =? Debugging => Set run in 64 bit to false.
I think you can get away by just installing the OLEDB Drivers -
http://www.microsoft.com/en-us/download/details.aspx?id=13255
I installed the "Microsoft Access Database Engine 2010 Redistributable" as mentioned above and got side-tracked troubleshooting bitness issues when it seemed to be a version issue.
Installing "2007 Office System Driver: Data Connectivity Components" sorted it for me.
https://www.microsoft.com/en-us/download/details.aspx?id=23734
The easiest fix for me was to change SQL Agent job to run in 32-bit runtime.
Go to SQL Job > right click properties > step > edit(step) > Execution option tab > Use 32 bit runtime
screenshot
You have probably installed the 32bit drivers will the job is running in 64bit. More info: http://microsoft-ssis.blogspot.com/2014/02/connecting-to-excel-xlsx-in-ssis.html
The easiest solution I found was to specify excel version 97-2003 on the connection manager setup.
I followed the instructions to use the /passive switch here, after downloading the 64 bit Access database engine. I'm running Office 32-bit, SSAS Tabular Model in SQL Server 2012. When I downloaded and ran the 64-bit Access database engine it came up with a message saying that I couldn't install this without first uninstalling Office 2010, but the /passive switch seems to have solved this (I can now import Excel workbooks and Access tables in a tabular model).
I was getting this same error after previously being able to complete similar operations. I didn't try downloading any of the mentioned packages since I didn't have them previously and things were working. IT at my job did a 'Repair' on Microsoft Office 2013 (Control Panel > Programs > Add/Remove - Select Change then Repair). Took a few minutes to complete but fixed everything.
Just install 32bit version of ADBE in passive mode:
run cmd in administrator mode and run this code:
AccessDatabaseEngine.exe /passive
http://www.microsoft.com/en-us/download/details.aspx?id=13255
I had this issue and it took me a lot of time to figure this out. #tara's answer helped me to solve this problem but I couldn't really find the setting to set run in 64 bit to false. So, here is the screenshot for where you can find the setting
If anyone is still struggling with this and have done all the above suggestions and Cry every time someone says install Database Access Engine. This is what sorted for it for me.
Install 32bit Database access engine as others have suggested.
Set to run in 32bit mode within Visual Studio
Set to run in 32bit mode on the Job Step within the job on SQL Server Agent. On the Step, General Advanced. Check 32-bit runtime.
I'd post some images but I don't have enough rep :(
I am trying to connect MS Access with a local mySQL database.
To do this I downloaded the mySQL ODBC connector from the mySQL website and installed it. As I am on a 64-bit system I went for the 64-bit version.
I then discovered when trying to connect Access to mySQL that my installation of Office is actually 32-bit so the driver doesn't work. So I removed the 64-bit ODBC driver and installed the 32-bit one.
Problem is, when I go into control-panel -> Administrative Tools -> Data Sources (ODBC) and try to add a new data source, the only options for the mySQL drivers seem to point to the old directory where the 64-bit drivers were. It then fails as it can't find the dlls with system error 126.
How do I get it to show the 32-bit drivers?
Run the 32-bit manager by running this command:
c:\windows\syswow64\odbcad32.exe
Also you can use RegisterDatabase() function to create connection from your code.
I wrote wrapper function many years ago:
http://5codelines.net/kak-programmno-sozdat-odbc-dsn/.
Just skip russian language and use the code.
Prior to installing the ODBC MySQL driver 5.2.6 you need to install the Microsoft Visual C++ 2010 Redistributable Package for x64 or x86 or both (just search the Microsoft site for these and download from there). Other driver versions may require different versions of this MS VC++ Redist. Package, which can coexist side by side. By default server 2008 R2 comes with the 2008 version, so installing the 2010 is required. Before installing check in Programs and Features if not already installed. Depending on you application it may require the 32 bit or the 64 bit version. Without it you get the system error 126
Then install the drivers:
To install the 32 bit version run as administrator c:\windows\syswow64\odbcad32.exe which is the 32 bit version of "Data Sources (ODBC)"
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.