In order to connect to a 64 bit Database (Oracle / DB2 / Postgresql/ SQL Server) from a 32 bit Software via ODBC, do I need the 32 bit Database client or just the 32 bit ODBC Driver would suffice.
As an example from Oracle, when I am installing Oracle Server, the 32 bit ODBC Administrator, does not necessarily have an entry for Oracle as the 32 bit ODBC Driver does not exist. In order to connect, I had to install the 32 bit Oracle Client, after which I can see an ODBC entry.
So my question is, in order to connect to a 64 bit database from a 32 bit application, do I need the 32 bit database client (thin/full) or just there exist a 32 bit ODBC driver which can be installed to establish a connection.
Which client you use is dependent on the architecture of the client machine you are using, not the server.
IIRC, with Oracle you need to install the client AND the ODBC driver. The client actually handles the connection to the database while the ODBC layer translates ODBC-speak to something the client understands.
I assume other platforms are similar although it is possible some databases supply an unified client installer that can install both the client and the ODBC driver.
When using ODBC, it is important to use the ODBC architecture that matches your client application. For example, If you are using x86 Access you would need the 32 bit ODBC driver and client.
When I setup a SQL Linked Server to Oracle, I installed:
Net Configuration Assistant
Net Manager
ODBC Driver
OLE Driver
The driver architecture should match the machine architecture. In my case it was 64bit Windows Server, so I used the 64-bit driver (win64_11gR2_client.zip).
I then ran the Net Config. Assistant and setup the oracle config (host/port/user/pass/service name). Make sure you pass a connection test here. This will configure your tnsnames.ora file (%path%\product\11.2.0\client_1\network\admin\tnsnames.ora)
If you can't connect, look into the sqlnet.ora file. I had to alter mine to read SQLNET.AUTHENTICATION_SERVICES= (NONE) before I could connect successfully.
I then ran ODBC to setup a System DSN using the same name setup in the Net Config. Assistant.
Following is valid for Oracle, I don't know if it all applies also for other RDBMS.
Database server and client are independent from each other, i.e. you can connect with an 32-bit Oracle Client to a 64-bit Oracle database server.
However the architecture of ODBC-Driver and Oracle Client have to match, i.e. a 32-bit ODBC driver works only with an 32-bit Oracle Client, a 64-bit ODBC driver needs the 64-bit Oracle Client. This restriction applies also for other providers like OLE DB or ODP.
A 64-bit Oracle client requires a 64-bit Windows, of course. Installing a 32-bit Oracle client on 64-bit Windows is no problem.
It is also possible to have both 32-bit and 64-bit Oracle client (and thus both architectures of ODBC drivers) installed on the same machine. However, you have to do a few "tricks" to make them both working seamless.
Related
My system has both 32-bit and 64-bit Redshift ODBC drivers installed. It shows up in the ODBC Data Sources under System DSN tab. However, only 32-bit driver shows up in the Drivers tab.
Also, when I attempt to make a Redshift connection by specifying 64-bit in the connection string Driver={Amazon Redshift (x64)}, I get this error: "ERROR [IM002] [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified".
Only the following in the connection string seems to work Driver={Amazon Redshift (x86)}.
I tried
Re-installing and repairing 64-bit driver.
Removing 32-bit driver from the System DSN tab
But none seemed to work.
Am I missing something?
We had the same problem using the Amazon Redshift driver in our ASP.NET application at our company.
If you're also using the Amazon Redshift driver in an ASP.NET application, I hope what we figured out (the hard way) might help you.
The solution to the problem is to use the 64-bit driver if you're running the application with the 64-bit IIS, and to use the 32-bit driver if you're using the 32-bit IIS. The thing that caught us off guard is that even on a 64-bit machine running 64-bit Visual Studio, the default IIS is 32-bit, not 64-bit. (https://www.jc-tech.info/2016/09/24/running-32-bit-or-64-bit-iis-express/)
This explains why only the 32-bit driver is found by your application. Regarding why the 64-bit driver does not appear in the Drivers tab of the ODBC Data Sources Manager, there are actually 2 versions of the ODBC manager: a 32-bit version, and a 64-bit version. The 64-bit driver will only show up in the 64-bit ODBC manager.
When debugging your application, if you want to make sure that Visual Studio is using the 64-bit IIS, go to Tools>Options>Projects and Solutions>Web Projects, and tick the "Use the 64 bit version of IIS Express" checkbox.
Similarly, when you deploy your application, make sure that your driver version (32 or 64 bit) matches the version of your production environment.
Had same problem,
I kept only 32 bit driver and uninstalled 64-bit and I put
Driver={Amazon Redshift (x86)}.
It worked fine.
More info can be found from below link.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/480db31c-b583-4c22-a7eb-bc37ad3a3e6d/data-source-name-not-found-and-no-default-driver-specified-error-in-report-builder-when-adding-an?forum=sqlreportingservices
If you are building a .NET application check the project properties for Build option to target x64 platform instead of using Any CPU option to target all
PostgreSql Bulkloader step is applicable in local system and if so is it possible to implement this step for JNDI connection
If you are considering your LocalSystem as a Window's Machine, it didnt work for me where the db was in a linux machine and the pentaho was in windows. It has got some issues with dual OS. Check this issue. But ideally on a windows to windows db , bulk loader step should work.
But for a Linux System, it works fine. I am not sure about MacOS.
For JNDI Connection: You cannot use a JNDI database connection since its not supported.
Please check this link.
Hope this is what you are looking for :)
I have a SQL Server, all I know about it is that there is no ODBC data source setup on the machine and I need to connect to it from C++. I have a username and password, how to connect to it?
You can connect using ODBC without a DSN using SQLDriverConnect. Specify the name of an installed driver in the connection string. A SQL Server Native client 11 example:
Driver={SQL Server Native Client 11.0};Server=SqlHostName;Database=SomeSqlDatabase;UID=YourUserName;PWD=YourPassword
Code snippet:
retcode = SQLDriverConnect(hdbc
, NULL
, (SQLCHAR*)InConnectionString
, (SQLSMALLINT)sizeof(InConnectionString)
, (SQLCHAR*)OutConnectionString
, (SQLSMALLINT)sizeof(OutConnectionString)
, (SQLSMALLINT*)StringLength2Ptr
, (SQLUSMALLINT)DriverCompletion
);
EDIT:
The driver name in the connection string must be enclosed in curly braces and exactly match one listed under the Drivers tab of the ODBC Data Source Administrator tool (odbcad32.exe). The ODBC driver named "SQL Server" ships with windows but a legacy driver provided for backwards compatibility. One should generally use a separately installed ODBC driver, which supports the newer data types and features added since SQL Server 2005.
The latest SQL Server ODBC driver as of this writing is the stand-alone "ODBC Driver 13 for SQL Server" (version 13.1).
I personally use SQL Server Native Client (OLE DB) in my C++ application to work with SQL Server 2008. And all I need is server IP address, port, username and password to connect to it. (We use SQL Server authentication, not Windows authentication). To develop/compile such application I need only sqlncli.h and .lib
The SQL Server Native Client OLE DB provider is a low-level COM API
that is used for accessing data. The SQL Server Native Client OLE DB
provider is recommended for developing tools, utilities, or low-level
components that need high performance. The SQL Server Native Client
OLE DB provider is a native, high performance provider that accesses
the SQL Server Tabular Data Stream (TDS) protocol directly.
SQL Server Native Client provides OLE DB support to applications
connecting to SQL Server.
It is low level, but gives access to all features of the server. For example, I call stored procedures with table-valued parameters and I use types like varbinary(max).
Have a look a this article When to Use SQL Server Native Client
SQL Server Native Client is one technology that you can use to access
data in a SQL Server database. For a discussion of the different
data-access technologies, see Data Access Technologies Road Map
When deciding whether to use SQL Server Native Client as the data
access technology of your application, you should consider several
factors.
For new applications, if you're using a managed programming language
such as Microsoft Visual C# or Visual Basic, and you need to access
the new features in SQL Server, you should use the .NET Framework Data
Provider for SQL Server, which is part of the .NET Framework.
If you are developing a COM-based application and need to access the
new features introduced in SQL Server, you should use SQL Server
Native Client. If you don't need access to the new features of SQL
Server, you can continue to use Windows Data Access Components (WDAC).
For existing OLE DB and ODBC applications, the primary issue is
whether you need to access the new features of SQL Server. If you have
a mature application that does not need the new features of SQL
Server, you can continue to use WDAC. But if you do need to access
those new features, such as the xml data type, you should use SQL
Server Native Client.
Both SQL Server Native Client and MDAC support read committed
transaction isolation using row versioning, but only SQL Server Native
Client supports snapshot transaction isolation. (In programming terms,
read committed transaction isolation with row versioning is the same
as Read-Committed transaction.)
For information about the differences between SQL Server Native Client
and MDAC, see Updating an Application to SQL Server Native Client from
MDAC.
I am developing a c++ application, which uses MS Access 2000 (back end database).
What is the best method to communicate with the database.
I can see a variety of options in msdn like
ODBC
OLEDB
DAO (Data Access Object)
From the below link, Microsoft says ACE engine should be used to communicate with Access 2007.
http://msdn.microsoft.com/en-us/library/cc811599.aspx#Ac2007DevelopingSolutions_Overview
Whether ACE engine can be installed in windows xp ??? so that my application can support both MS-Access 2000 and MS-Access 2007.
By the way, the application have to be ported to Linux. Is that possible to connect Access database from linux ?? (application in linux and database in windows)
Thanks
OLEDB / ADO is the best on Windows, but if you need to port to Linux and don't want to re-write all of the db access stuff, I'd stick with ODBC.
Evolution of this question
This started as an attempt to find other recommendations for running Django on Linux, accessing SQL Server via Django-PyODBC, and supporting Unicode as competently as in installations running Django on Windows.
After failing to materialize with a good solution for ODBC drivers in Linux that would provide the same level of support for Unicode as the Windows ODBC driver; the question morphed into coping with the negative side-effect of not having an Apache daemon mode in Windows.
The question
If you run Apache+mod_wsgi on Windows, every time you deploy new Django code you are required to restart the Apache server. See Graham's answer for details on why.
How to run a dependable set of applications and services when you might be required to restart Apache, denying service until it completely restarts?
The issue
We use SQL Server 2005 and we need to support unicode characters and certain characters (like smart-quotes) generated in Microsoft Office applications.
Running Django atop SQL Server 2005 requires us to use Django-PyODBC. It works great on Windows/Linux/Mac OS X; but if you require unicode support, you are out of luck on Linux / Mac OS X - the ODBC drivers for SQL Server in Unix are in varied stage of unicode compliance. FreeTDS, the open source driver, works for some characters if you specify a client character encoding of UTF-8 (*); but doesn't support all characters.
In our tests, running Django on Windows 2003 and using the Microsoft ODBC driver allowed us to properly insert/update/select any character in several different languages, and the Microsoft smart characters from Office applications.
But running on Windows means that every time we deploy new code we are required to bounce Apache - which means a few seconds without service.
(*) The only way we managed to get to the point where some characters would be accepted with FreeTDS, frankly, was to add a client charset entry to freetds.conf:
[a_db_server]
host = a_db_server
port = 1433
tds version = 8.0
client charset = UTF-8
In relation to reloading on Windows when using Apache/mod_wsgi, read my response to:
Server software choice for Django live/staging
Might be bad form to accept one's own answer, but it suited our case and it may help others...
First and foremost: we gave up trying to find an ODBC driver that would work properly with PyODBC and support unicode as competently as the Microsoft native ODBC driver. FreeTDS works partially, and some of the commercial drivers out there just didn't cut it in our tests. We considered a ODBC-JDBC bridge, but never really tested it.
We also thought about using an ODBC router, but given the price for a multi-user solution, the potential for more complexity, and the low load scenario for our Django apps; we decided to just stick with running Django on Windows and try to cope with the requirement of restarting the Apache server every time a new version of any of the Django apps is deployed.
What we did to cope with the Apache restart and still provide service availability:
We deployed an Apache server as a proxy/load-balancer to a cluster of (at the moment) two Apache servers running on Windows
On each of the Windows Apache servers in the cluster we have all our Django apps running
When new code must be deployed to the servers we:
Disable one of the servers in the cluster via Apache's balancer-manager interface
Apply the updates and install any new Django apps in the disabled server
Test the modifications in the disabled server
Reenable the the server in the cluster via Apache's balancer-manager interface
Perform the same steps for the second server
As long as one of the servers in the cluster is enabled and running, the applications and services are available to our users - no interruption. At the same time we gained some load-balancing (in our case we really don't need it at this point).
The proxy Apache servers rewrites all the redirects and cookie response headers, so as long as people are accessing the services through the proxy, there are no modifications needed in the Django code whatsoever.