VB Data Object

I am developing Banking Application with SQL-Server - 7.0
I want to known which data object has good connection speed
and with less resources.
 RDO  Or   ADO ?

I have heared ADO still has some bugs with vb-6.0 but
I think in ADO, ActiveX Componants of ADO and COM its-self
   spend resources of client
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Easy one...ADO all the way.  What some good reasons or is that enough?  Just kidding.

Microsoft announced some time ago that they would begin to phase out use and support in the application development strategies, the use of DAO and RDO...that in and of itself makes the question easy.

Furhtermore, ADO is much more robust than RDO offering some very powerful asychronous operation capabilities with recordset, connection, and command objects that were not previously available...offering unprecedented control over giving the user more information about what is happening during heavy data processing.

ADO, obviously an ActiveX COM object, supports OLE DB for more tightly integrated access to your databases.  If you are going to continue to use SQL Server, this will please you to know end...especially if you are fortunate enough to use the new Data Environment Designers in 6.0 which tie in to the technology tightly and integrate well with MS SQL Server.

ADO is a good strong model that yes, needs improvement.  There are always decisions that have to be made as to which is the best driver to use, should I be doing more processing on the server vs. client...what kind of recordset do I really want to get back.  But it is always improving and so far, Microsoft has been pretty good at deprecating funcationality, not elminating it..and 2.5 promises to be even better.

Finally, the nice and easy extensibility factor.  If you write a middleware piece as an ActiveX DLL using ADO, you will be able to use that same DLL from an ASP page in your inevitable move to web based development.  If you have a very basic model computer ADO can pig out a little but with anything over 64 Meg of memory and 133 mhz I have never even questioned its performance.

So scalability, good architecture, Microsofts choice for the future and extensibility...even into XML...all these reasons make the choice simple and forward thinking.

Hope that helps you to make a decision.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic Classic

From novice to tech pro — start learning today.