I am trying to import a MS ACCESS 2010 database into a new MySQL database.
Since I have a 64 bit machine I have used the ODBC tool ODBCac32 to create a 32 bit ODBC connection since the 64 bit ODBC administrator has an issue with a 32 bit application.
The issue I am having is that the MySQL workbench is using the 64 bit ODBC connector and then fails to import. Is there a way to force it to to use the 32 bit ODBC connector and 32 bit ODBC connection?
Thanks
Related
ODBC-call failed.
Specified driver could not be loaded due to system error 193
(MS ODBC for Oracle, c:\windows\sysWOW64\msorcl32.dll) (#160)
I have searched everywhere for a solution to this issue.
Currently, I'm running Access on a remote machine that is on Windows 7 Pro. Company wants this old computer gone, but I can't let it go until my new machine can talk to Oracle via Access.
I have followed the instructions for setting up a new ODBC connection to CosmosDB. I would like to use this ODBC connection in an SSAS tabular project but I don't see a way to do that. I am on SSDT 15.1. When I click the "Others" data source for OLEDB/ODBC in SSAS, it only gives me build options for OLEDB. It's not clear how I would use this to connect to my CosmosDB ODBC.
Has anyone figured out how to do this? According to Microsoft it is possible but they have no instructions for it.
It is possible. Launch the "ODBC Data Sources (32-bit)" app and setup a system DSN as described in this article. Then open "ODBC Data Sources (64-bit)" and setup a system DSN with the exact same name as the 32-bit DSN. The reason is that Visual Studio is 32-bit so when performing some steps it requires a 32-bit driver, but once SSAS loads the table into memory that occurs in a 64-bit process which requires the 64-bit driver. Setup these DSNs on your workstation and on the workspace server (local if using the integrated workspace or on a dev server if using a remote workspace).
Using ODBC drivers inside Analysis Services Tabular doesn't seem to be very well documented. Basically you need to use the OLEDB for ODBC driver.
When creating a new connection in Visual Studio in your SSAS model, instead of choosing the driver from the dropdown, just type in the following connection string:
Provider=MSDASQL;DSN=YourDsnNameHere
If you prefer inline connection strings that make deploying easier to do without ODBC DSNs then you can use this connection string:
Provider=MSDASQL;DRIVER={Microsoft DocumentDB ODBC Driver};Host="https://yourcosmosdbname.documents.azure.com:443/";AuthenticationKey="authKeyHere!";LocalSchemaFile="c:\folder\yourCosmosSchema.json";KeyEncrypted=true;NumberOfRetries=5;DSNType=0;Consistency=1
Regardless of which connection string you will probably have to write a query such as select * from CollectionName rather than picking from the table list.
If you are using 1400 compatibility level models (Analysis Services 2017 or Azure Analysis Services) then you should consider using the modern get data experience which has native Cosmos DB integration that's a lot more polished.
My application is in classic asp. Till now it is working fine with 32bit windows server and connecting oracle via a system DSN which is prepared with "Microsoft ODBC driver for oracle".
Now, the server has been migrated to 64bit Windows server 2008 R2. We have some third party dlls, which also have 64bit available. So, I deploy the application in IIS 7.5 and it is working fine.
In new server, I am using Oracle driver, as for 64bit, there is no driver of "Microsoft ODBC Driver For Oracle". Everything is working fine, except, when I try to fetch a record-set, it is returning nothing. No Error message, no data, nothing is coming.
Also, I can't change the app pool compatibility with 32 bit to "True", because, there are some third-party component which will only work in either of one environment. Either 32 bit or 64 bit.
So, my concern is, whether I can work with both the DSN[32 and 64]? OR any other idea to run the application.
Could you use an OLEDB driver instead. Oracle certainly provide a 64 bit OLEDB driver, and it could well be installed on your server already.
http://www.oracle.com/technetwork/database/windows/downloads/index-090165.html
Here's another useful link, with a very friendly URL
http://www.connectionstrings.com/oracle/
ODBC isn't generally regarded as the best way to go, unless you're using MySQL when it's pretty much your only option
I have a freshly built 64-bit Windows Server 2008 R2 box that I have installed 64-bit Coldfusion 9 Standard on. I've upgraded and hotfixed it up to the most current version of CF. I also had 64-bit Oracle 11g (11.1.0.7.0) Client installed on the box. I've created a System DSN using the 64-bit ODBC Data Source Administrator in Windows and can successfully test the connection of the data source.
All of these installations went smoothly, however, when I went to add a datasource in the Coldfusion Administrator I receive the error:
Connection verification failed for data source: myDatabaseName
java.sql.SQLException: [Macromedia][SequeLink JDBC Driver][ODBC Socket]internal error: The specified DSN contains an architecture mismatch between the Driver and Application
The root cause was that: java.sql.SQLException: [Macromedia][SequeLink JDBC Driver][ODBC Socket]internal error: The specified DSN contains an architecture mismatch between the Driver and Application
I am having a hard time understanding exactly where this architecture mismatch is coming from since the box is entirely 64-bit. I see while looking at all the processes that are running, some related CF processes are running in 32-bit (Verity related processes, SOLR and CFDotNetSVC). I am not sure if those could cause this issue but I am at a loss to explain were this mismatch would come from otherwise.
Anyone have any ideas?
Using Dan's advice I grabbed a JDBC Driver from Oracle here:
http://www.oracle.com/technetwork/database/enterprise-edition/jdbc-111060-084321.html
I then moved the JAR (ojdbc6.jar in my case) and added it to my Coldfusion Class Path.
Determining the correct settings for using the datasource to Coldfusion was slightly harder but here are the settings I ended up going with:
JDBC URL: jdbc:oracle:thin:#//dbsrv.mydomain.com:1521/myDB.world
Driver Class: oracle.jdbc.driver.OracleDriver
Driver Name: Oracle Thin Driver
Then the username and password for the DB.
Sure enough it worked like a charm.
Dan, I want to give you a check mark because you definitely put me in the right direction, but I can only mark one correct.
I believe you need to either step down to the 32-bit drivers, or use native JDBC drivers to connect to Oracle successfully. My suggestion would be to go the JDBC route, and connect directly through a native Oracle JDBC driver by using the "other" selection on the Datasource screen. You'll get better performance that way, and have more control over your connection via ColdFusion.
Connecting to Oracle information in ColdFusion Livedocs.
i found an alternate way to do this
install the ODBC drivers for 64bit and 32bit (in that order) on your win2008 64bit OS
thereafter create the DSNs on both the System32 folder and SysWow64 folder by running the odbc32ad32.exe
ensure your tnsnames are setup fine in the respective network/admin folder (if you use tnsnames to maintain your sids)
now on the CF admin you creaet a new ODBC source with aODBC Socket and name. the next page should show you a drop down of all DSNs that exists in the 64bit DSN setup. When you go and test it in CF, it will strangely use the config of the 32bit DSN setup for validationb
voila....your connections should work. No worries of those architectural failures etc
We needed to setup 64 bit ODBC connections for a ColdFusion 11 server to query against 2012 SQL Server instance on Windows 2008 R2 Server. The ODBC connections would show up but would never work. We received so many various messages when verifying such as "needing SSL connections to work" and also timeout messages as it was having problems logging into SQL Server.
I stumbled across this post and we decided to follow setting up 64bit ODBC connections and then effectively overwriting them--preserving the name using the 32bit ODBC. Thank you again fellow developers, especially Souzam! My instructions are below:
For Windows 2008R2 Server you must disguise 64bit ODBC socket configurations for 32 bit in order for them to appear in CF Admin as datasources (obvious bug in CF 11):
Creating 64bit ODBC connections via 2008 R2 ODBC application, follow a naming convention that will allow you to recall in 32 bit configuration.
Configure ODBC 32bit connection in SYSWOW64 (C:\Windows\SysWOW64) using the odbcad32.exe using the previous 64bit names in Step #1.
Create data sources in CF Admin as these should appear in a dropdown when creating ODBC Socket Type connections.
This question already has answers here:
what is the difference between OLE DB and ODBC data sources?
(11 answers)
Closed 10 years ago.
What is the difference between OLEDB and ODBC? When do I use which and how do I know what I am looking at is a OLEDB driver v/s an ODBC driver?
OLEDB and ODBC are two different database API's. ODBC is an older standard and is actually not specific to windows - you can get Unix-based ODBC libraries. OLEDB is a COM-based API for database connections.
There is a driver for wrapping ODBC with an OLEDB front-end if the database you are using does not come with a native OLEDB driver. IIRC DB2/400 and Sybase OLEDB drivers (for example) use this method.
The ODBC administrator in Windows is only concerned with ODBC drivers. Both ODBC and OLEDB can use connection strings, which have a slightly different format. You can tell from the connection string - www.connectionstrings.com has samples of connection strings for many different database drivers.
Edit: Oracle has a driver technology for every day of the week.
Oracle have a native OLEDB
driver called 'Oracle provider
for OLEDB' or some such. If you're
using ADO (non-.Net, which sits over
OLEDB) this would be the preferred
driver.
They also have an ODBC driver
that would be (for example) useful for
extracting from an Oracle database
into MS-Access or with an application or system that does not support OLEDB. For example, older Delphi/Oracle or Powerbuilder/Oracle apps will probably use this driver.
Oracle also has an
Oracle-specific interface called
OCI. This is the fastest
interface if you're writing in C and
will also work on non-windows
plaforms but ties your application
to Oracle. Dynamic language bindings such as cx_Oracle for Python tend to be wrappers around OCI.
If you're using .Net you probably
want ODP.Net rather than
using the .Net provide for OLEDB. This is the
standard .Net interface library
provided by Oracle.
There are several JDBC drivers for
Oracle. There is a type-2 driver
which is a wrapper for OCI and a
type-4 driver which is written
natively in Java and communicates
directly over the network to the
server. If you're using Java the type-4 driver is probably the best for most applications (you don't have to install a full Oracle client) unless you have a particular reason to need the type-2 driver.