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 new to database programming.
I am trying to make an application that interacts with a database file locally so that I can use those database query.
I tried to use mySQL connection c++ 1.1.6, and run this example.
Following error is what I get:
MySQL server on '127.0.0.1' <10061> <MySQL error code: 2003, SQLState:>
I guess that I need to have a server on for connecting. What I want is just an interaction with a database file locally, do I need to make this connection also? If I really need this connection, how to make it works?
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.
Is it possible to connect to an Oracle DB using a jdbc connection string like:
jdbc:oracle:thin:#myserver:1521:mydb
inistead of using TNS?
Yes, as long as the JDBC driver JAR is in the CLASSPATH.