Visual Basic.Net and SQL Server 2000?

Question

I currently write software using Microsoft ActiveX Data Objects (ADO) 2.8 in VB6. The software interacts with database tables, views, and stored procedures on our SQL Server 2000 database. Most of what I do involves commands, sometimes returning recordsets, but usually just parameters. I create the objects as needed in code and do no deal with ADO controls on forms at all.

I'm about to begin working with VB.Net 2003 (and hopefully soon 2005) and would like to find references and hints as to what are the most efficient and easiest methods to do this. Please answer with the fact I'm not too familiar with VB.Net in mind.

Thanks.

I really appreciate all the answers so far. I've been reading through the information and have already ordered a book. When working with VB.Net using ADO.Net, do I need to add any particular references or simply type the three imports lines at the top of the solution? I noticed the ADO.Net objects in the toolbox, but hesitate using these in VB6. Should I try to avoid them in .Net as well? Thanks again.

Answer 1

ADO.Net is a very, very different style of database programming. It heavily emphasizes disconnected data handling, and has a number of objects (such as the DataView) that have no parallel at all in ADO. I found it really difficult to learn, because a lot of the operations in ADO that seemed straightforward are a little more involved in ADO.Net.

For instance, you can use an ADODB.Recordset with an AdOpenKeyset lock, and add a new record without doing any extra work than you'd have to do reading the database... other than adding an .AddNew and .Update call.

In ADO.Net to do a similar operation, you have to make a Data adapter with the SQL call, create a datatable, fill the datatable with the data adapter, then make a command builder, and generate the SQL commands for the data adapters .InsertCommand property. Then you have to make a datarow out of the datatable's newrow method and.... well, I'd have to go on a bit to fully describe it to you.

However, after five years of working with this, I'm definitely an all-out convert. I think the changes allow you to move a lot of the power - for things like paged grids on web pages, number crunching, sorting and filtering - off the database and into the middleware or client web page or app.

But the changes in work style are so immense that I'm not sure a web reference is good enough. There are some must-see sites:

http://samples.gotdotnet.com/quickstart/howto/

(see "Data and ADO.NET")

http://www.sitepoint.com/article/introduction-ado-net describes the strategic approach taken with ADO and then ADO.Net - useful for a transitioning developer.

But I think you'd do best with a book - I would never have gotten good with ADO.Net without "ADO.Net Programming". There's a VB.NET version of this book - ISBN 1861008066. I really suggest a book, whichever you get.

Answer 2

Okay, first thing you have to keep in mind that the only similarity between ADO and ADO.NET is the name.

For a quick comparison between the two, plz check ADO.NET DataSet versus ADODB.RecordSet under:
http://www.vbip.com/books/1861005563/chapter_5563_09.asp

I suggest that you also read
http://msdn2.microsoft.com/en-us/library/ms973217.aspx

The most well known objects associated with ADO.NET are the Dataset, the Command, and the DataReader objects.

The first new flashy thing you will attract your attention in ADO.NET is the Dataset and how it allows you to work in a "Disconnected Scenario". This might tempt you to attempt to use the Dataset in every occasion and that's the primary common mistake taken by developers newly learning ADO.NET.

If you're application does not need to retrieve Data and work with Data disconnected from the datasource before updating the data, stick to using objects in the ADO.NET that allow a "Connected Scenario" data access such as the DataReader.

You have to do a lot of reading before writing code or otherwise you will end up with code that is functional but "abuse" the technology. That is why developers used to say that ADO.NET is slower when they first started using it(cz they abused it).

You should check ADO.NET under Microsoft's site for a list of articles on the technology and best practices.

For good books on ADO.NET i suggest you check books by Apress and Wrox (for ADO.NET 1.1 and ADO.NET 2.0)

Hope this helps.

Answer 3

provided that sq. 2008 has been out for a on the same time as i could stay far off from 2000 and concentration on 2005 and 2008. do no longer anticipate any save could have a single version of the DB around. we are at present deploying 2008 for brand spanking new systems we setup and present 2005 systems would be migrated over the subsequent twelve months. i does no longer waste any time on 2000 until there's a particular pastime you're going for that makes use of it.