Need opinions on DAO and VC7
-
I'm looking for advice/opinions on DAO vs ADO vs ODBC converting an MFC/VC6 app to VC7(.net) All my DAO functions have been declared deprecated in VC7 so I'm a little nervous regarding future support. Can I do the same things with ADO/ODBC as I can with DAO - I need to be able to create the Access database as well as read and write to it. How about performance -DAO vs. the rest. Or should I start thinking about deploying personal SQL server on all my machines in the field. In that regard can I look at a SQL server database with Access (all my users are familier with Access, so loosing that functionality is a drawback) Also have some odd things happening with DAO in VC7 - like the connection being closed when returning from a function (as if the destructor gets called when it shouldn't) I know thats a lot to ask, but any and all opinions or help will be greatly appreciated. Thanks in advance, John Horstkamp
-
I'm looking for advice/opinions on DAO vs ADO vs ODBC converting an MFC/VC6 app to VC7(.net) All my DAO functions have been declared deprecated in VC7 so I'm a little nervous regarding future support. Can I do the same things with ADO/ODBC as I can with DAO - I need to be able to create the Access database as well as read and write to it. How about performance -DAO vs. the rest. Or should I start thinking about deploying personal SQL server on all my machines in the field. In that regard can I look at a SQL server database with Access (all my users are familier with Access, so loosing that functionality is a drawback) Also have some odd things happening with DAO in VC7 - like the connection being closed when returning from a function (as if the destructor gets called when it shouldn't) I know thats a lot to ask, but any and all opinions or help will be greatly appreciated. Thanks in advance, John Horstkamp
From experience ADO and MSDE are the way to go. I switched about 3 years ago from DAO to ADO because DAO is not thread safe and my applications are all multithreaded. Also MSFT support for DAO is declining. There is a learning curve but it is worth it. Most examples in ADO used to be geared twards VB but that has changed a bit now. As for MSDE, its free and works fine for all my applications. The only problem I have had with it was we were hit with the slammer worm that also hit SQL server... Here is a good place to get you started: http://www.codeproject.com/database/caaadoclass1.asp[^] John
-
I'm looking for advice/opinions on DAO vs ADO vs ODBC converting an MFC/VC6 app to VC7(.net) All my DAO functions have been declared deprecated in VC7 so I'm a little nervous regarding future support. Can I do the same things with ADO/ODBC as I can with DAO - I need to be able to create the Access database as well as read and write to it. How about performance -DAO vs. the rest. Or should I start thinking about deploying personal SQL server on all my machines in the field. In that regard can I look at a SQL server database with Access (all my users are familier with Access, so loosing that functionality is a drawback) Also have some odd things happening with DAO in VC7 - like the connection being closed when returning from a function (as if the destructor gets called when it shouldn't) I know thats a lot to ask, but any and all opinions or help will be greatly appreciated. Thanks in advance, John Horstkamp
IMO, the benefits of ADO far outweigh that of DAO (ADO.NET is even better). With MS declaring DAO depricated in VC7, this not only means no support but also no backward compatibility. MSDE is more robust and has much more functionality than Access. Users can continue to use Access by linking to SQL Server.
-
From experience ADO and MSDE are the way to go. I switched about 3 years ago from DAO to ADO because DAO is not thread safe and my applications are all multithreaded. Also MSFT support for DAO is declining. There is a learning curve but it is worth it. Most examples in ADO used to be geared twards VB but that has changed a bit now. As for MSDE, its free and works fine for all my applications. The only problem I have had with it was we were hit with the slammer worm that also hit SQL server... Here is a good place to get you started: http://www.codeproject.com/database/caaadoclass1.asp[^] John
Thanks, So how does MSDE relate to SQL server? BTW - the app is not really a high performance database. The "admin" info is fairly trivial even for Access. The point of concern is that there is also a lot (can be really huge) numerical info (calibration data) that I store in the Access equivalent of a blob. Will I see performance gains with MSDE/SQL server?
-
IMO, the benefits of ADO far outweigh that of DAO (ADO.NET is even better). With MS declaring DAO depricated in VC7, this not only means no support but also no backward compatibility. MSDE is more robust and has much more functionality than Access. Users can continue to use Access by linking to SQL Server.
"...(ADO.NET is even better)" In what regards (or is that too open ended a question)?
-
From experience ADO and MSDE are the way to go. I switched about 3 years ago from DAO to ADO because DAO is not thread safe and my applications are all multithreaded. Also MSFT support for DAO is declining. There is a learning curve but it is worth it. Most examples in ADO used to be geared twards VB but that has changed a bit now. As for MSDE, its free and works fine for all my applications. The only problem I have had with it was we were hit with the slammer worm that also hit SQL server... Here is a good place to get you started: http://www.codeproject.com/database/caaadoclass1.asp[^] John
After doing a little research on MSDN it does seem that MSDE and ADO are the way to go...Downloading MSDE now. I may have further questions... Thanks for the response John
-
IMO, the benefits of ADO far outweigh that of DAO (ADO.NET is even better). With MS declaring DAO depricated in VC7, this not only means no support but also no backward compatibility. MSDE is more robust and has much more functionality than Access. Users can continue to use Access by linking to SQL Server.
After doing a little research on MSDN it does seem that MSDE and ADO are the way to go...Downloading MSDE now. I may have further questions... Thanks for the response John
-
"...(ADO.NET is even better)" In what regards (or is that too open ended a question)?
I guess it depends on what you're trying to do. Lately I have been working with XML out of databases and find that ADO.NET has much more functionality in that area. If your app is not using the .Net platform then it will probably be too much overhead to include with the distribution.
-
I guess it depends on what you're trying to do. Lately I have been working with XML out of databases and find that ADO.NET has much more functionality in that area. If your app is not using the .Net platform then it will probably be too much overhead to include with the distribution.
Don't have much experience with XML but I thought XML is more of a data transport mechanism as opposed to a data storage mechanism. Actually, what I am doing (for a variety of reasons) is changing an application from using the Microsoft serialization scheme to a relational database scheme. The app object model actually lends itself nicely to a relational database. The database (50 or more .dat files or 1 .mdb) is fairly stable - ie nothing changes - once a site is calibrated and up and running. The creation and calibration of a site is another story. The admin portion of the database is trivial - even for Access. There is however a large portion of numerical (calibration) data that I store as a blob. The app was started in VC6 and I am converting to VC7. It will run on Win2k and XP machines (and maybe NT at some old sites). I don't know if that's too much info...or even makes sense... or is relavent :) John