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.
Related
My program uses ADO to connect to SQL Server in Visual C++ 2008. Now it seems that ADO is out-dated and MS recommends to use ODBC again.
Therefore, I now study how to use ODBC to connect to SQL Server. I see there is a class CDatabase that can do that. However, there are no good article in introducing how to use CDatabase to connect to SQL Server via ODBC.
Basd on my research, it seems one can connect to SQL Server via ODBC in the following way:
Via a direct connection string like this one:
Driver={SQL Server Native Client 11.0};Server=myServerAddress;
Database=myDataBase;Uid=myUsername;Pwd=myPassword;
Using ODBC administrator to create a DSN(Data Source Name), and then connect with DSN.
THen if 1 works, why do we need to create DSN?
You don't need a ODBC DSN. A DSN simply allows one to externalize the ODBC configuration such that server name, driver. etc. can be configured in a common way for all ODBC applications.
It is not a requirement to use a DSN when you store connection string in an external file so that environment-specific values can be configured without code changes. Regardless of the technique used, be sure to protect secrets rather than storing as clear text.
I'm trying to send queries to a SQL database from a Windows CE 7 C++ application running on an ARM architecture.
During my research I found several possibilities to do this:
Use methods from system.data.sqlclient
Doesn't work, since the application is not supporting CLR
Use ODBC or OLEDB
I read at several points that both won't work on Windows CE
Use HTTP requests from winInet to send the data as JSON to the DB and parse it back there
Just an assumption that this could work, not confirmed
So I'm wondering what other/better ways there are to send these queries.
Thanks for your help!
If it is a pocket pc sql server lite database then you can use ADOCE to access and configure your database. The service'esqe approach is also valid and will take the data access burden from your client application.
you can implement your third option but you need to implement also another software component (on the SQL server side) to do the following work:
connect to the database;
decode the JSON and query the database;
encode the database answer in JSON and send back to your WEC7 application.
If you are familiar with C# and if you have .NET compact framework installed on your WEC7 machine you could also implement the software component that will send HTTP REQUEST in plain C# (without the need to study wininet).
Hope this helps
I am working with Informatica Developer - Power-Center. I have it installed on 2 computers: my local PC and the MS Server where the Informatica Server is also installed.
I defined a new connection and tested it by clicking Test Connection. On my PC the test works fine but when I test the connection on the server the test fails with the following error: "[REL_10611] Error returned during ODBC access. ErrorCode=[-1]. Reason=[[Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified]."
Another strange thing is that the mapping that includes a relational data object that uses this connection works even on the server and adds row to the DB.
Does anybody know why this could be happening? Is this a bug in the Informatica Developer?
Did you create the ODBC data source on the server? The data source needs to be created on both your local PC and on the server. When using the Developer Tool (and the Power Center client tools for that matter), some operations are executed from your local workstation and some are executed on the Data Integration Service (DIS).
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.
Context: I'm working on a project that use Offline Application Architecture. Our client program has 2 modes: connected and disconnected. When user in disconnected mode, they will use their local database (SQL CE) for retrieving and storing data. When user connects to application server again, the local database will be synchronized with central database as well. The transport layer in this project is WCF, we implement a proxy class to expose SQLSyncProvider on client for Sync Framework to sync data.
Question: How could I implement data filtering with MSF? In our project, each client will has a role, and each role will have access to different number of tables as well as rows in table. As far as I know, MSF allows us to filter data with a parameter column however, the provision for users will be same. In my case, the provision for each user will be so different, it depends on user's role.
Thanks.
You can use adapter filters on server side, and can send some parameter to fetch data on client bases from client.
Client
this.Configuration.SyncParameters.Add(
new SyncParameter("#CustomerName", "Sharp Bikes"));
Server
SqlSyncAdapterBuilder