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.
Related
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 learning to work with mysql and c++ in ubuntu os. There are several tutorials on how to interface mysql with c++ in visual studio or in windows, but not one for Linux. Mysql website also does not describe properly on this.
Can anyone suggest me a link to tutorial, book or any thing that gives information an how to interface c++ with mysql in Linux. My database is in linux machine itself.
Thanks for the great help.
Mysql is a database, and to gain access to the data within C++ you will need to be able to “talk” to the database via queries (just like on the mysql command line interface e.g. select * from tablename), the connection process is very similar to the command line interface you will need to supply connection details as in hostname (localhost normally), username, password, database to use and also there are other details that you can pass e.g port number more information can be gained from the MYSQL API pages.
This link has a good example
Connect mysql in c++ for unix
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 have 2 application running on the same machine.
Editor, is a Windows 8 application developed with WinRT and is sand-boxed. (Client)
Integrator is a C++ application for reading hardware devices over serial COM ports. (Server)
I have done a lot of searches about how to get client/server communication to work on Windows 8,
and can only find posts that say it is not possible using standard WinRT classes, etc.
What I need is a solution where by the Windows 8 application works as a client, and the standalone
executable works as a server.
Can someone please suggest a mechanism that can be used to do client/server communication.
If we cannot find a good solution for this, then we will have to resort to using files, which
I would rather not have to do.
Clarification: I am aware of the many mechanism that can be used to do client/server communication.
What I am looking for is a workaround to the problem, where the these techniques will not work on
a Windows 8 application, developed with WinRT. As the sand-boxing explicitly prohibits the client
and server being on the same host machine.
Well, the posts stating that such communication is not possible, are mostly right. There are 2 reasons, why this is prevented:
Being able to communicate to an application outside the sandbox effectively breaks the sandbox. The Windows Store app is now suddenly able to do everything the desktop application can do: access file system, registry... Windows Store apps live in a sandbox for reason - to be safe for the user.
The Windows Store app won't work after it is installed from the the store or from a package. It needs to have a desktop application installed and set up correctly as well.
I would suggest you try to move your server part to a different machine and make it a proper server. If for some reason you really can't do that, you still have the following options available:
You can use TCP/IP to connect local network resources if you remove the isolation for your Windows Store app. You will need to use CheckNetIsolation.exe, but since you already need to separately install the desktop application, this shouldn't be that much of a problem.
You can create files with a specific extension. Then register the desktop app for one extension and the Windows Store app for another extension. You can now shell execute files with these extensions to use them as a message for the other app.
I'm currently experimenting with build script, and since I have an ASP.net Web Part under source control, my build script should do that at the end:
Grab the "naked" Windows 2003 IIS VMWare or Virtual PC Image from the Network
Boot it up
Copy the Files from the Build Folder to the Server
Install it
Do whatever else is needed
I have never tried automating a Virtual Machine, but I saw that both VMWare and Virtual Server offer automation facilities. While I cannot use Virtual Server (Windows XP Home :-(), Virtual PC works.
Does anyone here have experience with either VMWare Server or Virtual PC 2007 SP1 in terms of automation?
Which one is better suited (I run windows, so the Platform-independence of VMWare does not count) and easier to automate?
With VMWare, there is the Virtual Machine Automation APIs (VIX API). You can find the reference guide here. It works with VMWare Server and WorkStation, but AFAIK it's not available for ESX Server.
From the main page for VIX:
The VIX API allows you to write
scripts and programs that automate
virtual machine operations. The API is
high-level, easy to use, and practical
for both script writers and
application programmers. It runs on
VMware Server and Workstation
products, both Windows and Linux.
Bindings are provided for C, Perl, and
COM (Visual Basic, VBscript, C#).
Use https://github.com/dblock/vmwaretasks rather than the raw VixCOM API if you're going to do this in C#.
I agree with Chris.
Virtual Machine Automation APIs is a very good possibility for automating of virtual machine operations.
VIX API Version 1.6.2 can be used for automating of ESX guest operations as well.
VirtualBox also has API's for automating their VM's.
To follow-up to #Chris, ESX is extremely scriptable. A client I've been working with recently has built a web service that launches a VMware script to create the VM they need, then start the VM with a custom boot ISO. That ISO includes all the kickstart or unattend.txt info it needs to do a totally unassisted OS build.