Hello:
I've been recompiling my old projects under VS2008 and got a bunch of compiler warnings that DAO is deprecated. So what are we supposed to use now from within an MFC project? (in VS2008 and VS2010 IDE)
Printable View
Hello:
I've been recompiling my old projects under VS2008 and got a bunch of compiler warnings that DAO is deprecated. So what are we supposed to use now from within an MFC project? (in VS2008 and VS2010 IDE)
I moved to used ADO.
Some other guys use MFC CDatabase/CRecordset classes...
Thanks for your answer. I'm kinda out of the loop on this one. In one of my future projects I will need to use a database for accounting purposes. Which engine would you recommend? The database will most certainly have thousands of payment records, hundreds of customer data, etc. In other words it may grow really big with time.
"thousands of payment records" as well as "hundreds of customer data" is almost nothing. A "big" Db begins with at least " hundreds thousands of ... records"
Well, I already chose ADO & SQL Server 2008 Express (since it is free).
You personal choice would depend on your DB and your DB structure: if there are only some separate table in the DB then CDatabse / CRecordset classes together with the record-binding (or without it) would be the simplest choice. If there is a lot of relationships between the tables / views - ADO seems to be better choice...
I apologize for my ignorance, but again I'm really behind on this subject. You're saying that ADO is based on the SQL Server Express, right? Doesn't it cost like thousands of dollars just for the license to it?
ADO has nothing to do with Sql Express. It means ActiveX Data Objects and uses COM to access the datasource.
Search Bing or Google for "ADO database c++ tutorial"
Another option is to use the ATL OLEDB Consumer classes. In my opinion they are easier to use than ADO (because they hide the COM) and far easier to use than the MFC CDatabase/CRecordset classes. Search this forum for sample code. I wrote a lengthy reply a few years ago about connecting to an Access db using ATL. It isn't much different to use ATL to connect to a Sql db (or other datasources), so the sample code is the same except you choose a Sql provider at the beginning.
Btw ADO or the ATL OLEDB Consumer classes are pretty much data source independent. There are providers for Excel, Access, ODBC db, Sql, flat file, Outlook and many other types of data.
I once used ATL OLEDB Consumer to connect to an Access db for a standalone MFC app. No Office license was required and Office didn't need to be installed on the client's machines.
In terms of Microsoft Sql, there are many price points and the Express and Compact Editions are free. Here is the link for the Compact edition. http://www.microsoft.com/sqlserver/e...s/compact.aspx
Click on the Editions tab to see the Express and other editions.
Thanks, Arjay. I see that a lot of Microsoft technology these days comes with the use of .NET and a multitude of code that they wrote for it (when interestingly enough I don't see it being used that much for their own Office products). It also seems like the development of common controls (GUI) available for the public has been completely stopped in the native world.
I personally try to stay away from .NET mostly because of it's "bulk". Let me explain. When I write my software I prefer it to come in a "small package", meaning that it needs the main executable plus a handful of optional DLLs it may require, and that is it. With .NET it's almost like you need a lot of pre-installed DLLs to be available on the system, or I need to lug a huge installer that is not even written by me or my colleagues.
Well, OK, you may say that with my minimalistic approach I'm losing big on the amount of time it may require to write my software, and I agree with that. But, what I am winning at is the speed with which my software itself can run as well as its dependability when installing on various (older) systems that may not have the latest version of .NET installed. It may be my opinion though...
In light of that, let me ask a follow up question. So, if I need to find a database engine for the use with MFC (in VS2008/2010) that can handle thousands and potentially millions of records, something that doesn't require COM/Active X or .NET, what would you recommend I use?
ODBC API Functions.Quote:
Originally Posted by ahmd
Although I should say that ADO as well as MDAC 2.8 (if I remember it correctly) is installed by default together with OS, so you should not worry.
Do you understand the current penetration of .Net? It is like at something like 90% across the current users of Windows. Any service pack of XP comes with .Net. It ships with Vista and Win7. There's already 65% of machines with .Net 3.5 SP1 installed. For info, search bing or google for ".Net framework windows install penetration".Quote:
Originally Posted by ahmd
COM is built into the operating system since at least Win98 and NT4, so what is the issue?
If you need to connect with a MS SQL Database, use the ATL OLEDB Consumer classes - they don't require any external dlls and everything they need to connect to the database comes on XP and above. Because the classes are templated, they get compiled into your app so you don't need to include any additional dlls with the setup program.
I always find it interesting to view folks that do what I call "coding for the past" - in other words, folks that don't want to use a technology because a portion of their user base would need to install additional components. They end up with hard to maintain code because as time goes on it takes more and more effort to code using the legacy approach than it would be to code in the later technology.
In my opinion, the way around this issue is to simple write a smart installer that only installs dependencies when they are absolutely necessary. For example, consider .Net 2.0 as a dependency. The installer would only install the framework on machines that don't have .Net 2.0 installed already (either natively or through windows update) - that's getting exceedingly rare nowadays.
Thank you both.