Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations derfloh on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Wrapper for ADO to ADO.Net
- Thread starter varshan09
- Start date
sodakotahusker
Programmer
- Mar 15, 2001
- 601
Do you mean you want code written in vb.net to call ado ?
Or vb6 code to call ado.net code?
Or vb6 code to call ado.net code?
- Thread starter
- #3
What I mean is, we will write a custom class with the name of ADODB which will have all the properties and methods supported by ADO objects. However, implementation of these methods will have ADO.Net objects.
Has anybody already worked on it?
Has anybody already worked on it?
sodakotahusker
Programmer
- Mar 15, 2001
- 601
Yes I did it with my first VB.NET project. ADO is a COM based solution. Using the COM interOP lets you use any COM objects with dot.net .
- Thread starter
- #5
sodakotahusker
Programmer
- Mar 15, 2001
- 601
ADO and ADO.NET are two different animals.
The recordset of ADO exists no more.
If you are bringing data into your application, the only way you could write code the way you describe is by returning all of your data in arrays or assigning all individual fields in your class module (and that would be a pain in the butt - just as easy to move to ado.net now). So only that module references ADO. If you are just calling stored procedures to execute inserts, updates, deletions - then what you are proposing would be easier - but that does not seem like a real life scenario.
The recordset of ADO exists no more.
If you are bringing data into your application, the only way you could write code the way you describe is by returning all of your data in arrays or assigning all individual fields in your class module (and that would be a pain in the butt - just as easy to move to ado.net now). So only that module references ADO. If you are just calling stored procedures to execute inserts, updates, deletions - then what you are proposing would be easier - but that does not seem like a real life scenario.
ThatRickGuy
Programmer
If I understand what you want to do, It can be done. The question is should it. I know the pain that is migrating from ADO to ADO.Net, but that pain forced me to re-examine how I was handling data at the application level. Now, I have 2 classes that do all of the acutal ado.net code (One for SQL Sever, and one for OLEDB) All of my interaction takes place in an abstraction layer. So the App calls business objects, the business objects call data objects, the data objects call the appropriate data abstraction object, and that object calls the proper data base.
The joy is that I can create a set of data objects for tables on different databases, even in different types of data bases. I can then take those data objects and plug them into any app I make and have instant access to the database with out having to type a single line of ADO.Net code. With this template style we kicked out 20+ data gathering reports in under a week.
So as much as I prefer the 3 object model joy of ADO, I also appreciate the change in coding style that ADO.Net drove me too. That and under the hood, ADO.Net better performing and has some great tools.
-Rick
----------------------
The joy is that I can create a set of data objects for tables on different databases, even in different types of data bases. I can then take those data objects and plug them into any app I make and have instant access to the database with out having to type a single line of ADO.Net code. With this template style we kicked out 20+ data gathering reports in under a week.
So as much as I prefer the 3 object model joy of ADO, I also appreciate the change in coding style that ADO.Net drove me too. That and under the hood, ADO.Net better performing and has some great tools.
-Rick
----------------------
- Status
Similar threads
