Not too long back I was playing around with VC2010, looking to do more or less the same thing you are: get Access-like functionality from a .NET environment. I don't have a lot to say on it (I don't have the time I would like to spend with it, so haven't gotten very far), but maybe some comments will help:
It seems like there are a lot of major differences in how you have to think when using VB.NET.
Indeed. So many differences, in fact, that you need to learn .net with a clean slate. Most of what you may know from using Access will not apply.
Why you might choose VB.NET (or C#) over MS Access and Vice Versa
The power and level of detail that you can get using .NET far, far suprasses that of the Access interface. But it certainly comes at a price: what might take 10 minutes in the Access environment may take the novice .NET programming 10 hours. And then you have the 10 hour Access projects... it takes a lot longer to get things done in .NET. So, for me, when I absolutely need to have something done quickly and efficiently and not screw around with hours upon hours of testing/debugging, Access is the way to go. When I want to have a complete control over everything going on, whether it be UI or Data handling, .NET may be the way to go, so long as I don't need it done in a hurry.
Information on how VB.NET data adapters, datasets, data tables, etc, compare to MS Access Recordsets
I bought Microsoft ADO.NET 4.0 Step by Step
and found it extremely useful. In fact, I had purchased two or three other books looking for this information before I found this one, and wish I had found this first. It gives everything you need to know about how to handle data in ADO.NET. With this information, you can construct your own classes that act/feel like a traditional DAO or ADO recordset. Note that there is no "comparison" per say. With Access, you use the DAO and ADO models. With .NET, you use ADO.NET with the option to build your own model to replicate that behavior, if you wish. DAO and ADO are "dumbed down", so to speak, where ADO.NET gives you control over every piece of data, in more ways than you might ever want or need.
Also, LINQ and EF (ADO.NET Entity Framework) are highly recommended tools for working with data, though I would advise that a good understanding of ADO.NET before moving into these may be helpful.
Note that traditional ADO and ADO.NET are nothing alike. ADO.NET is not
a new version of ADO. It just happens to share the first three letters of the name.
Whether or not to use Visual Studio's data tools to create adapters, datasets, data tables, etc.
I don't recommend this. I think that we are far better off using code to do what we need to do... the VS interface creates many... issues... along with the data. This
is a thread I started when I was working with similar issues, where Brent and Anthony chime in with some very helpful advise regarding working with ADO.NET. It certainly made me feel more comfortable having people who know the environment advise on how to handle the situations. If I can quote Anthony from the aforementioned thread:
One bit of advice that I would suggest is to avoid using the Designers except with laying out a form. It makes for quite the mess, and you rarely get a full understanding of what is capable and how to effectively leverage that for your needs.
I often run into people who learn solely how to work with the Designers, and then when you go to provide them with a solution to something, they are completely dumbfounded at the concept of not using a designer. They don't get the methodology, and they struggle to pick up syntax.
I agree with this wholeheartedly.
When and why you might write your own UpdateCommand, DeleteCommand, or AddCommmand in VB.NET
Bound vs. Unbound forms in VB.NET
When to choose unbound forms in VB.NET
The SQL Commands are there for your use, and may be required to perform certain tasks when handling data. Similar to using SQL in Access with an UPDATE, INSERT or DELETE: use them when you need to.
Bound vs. Unbound is also a hard one to "compare" persay... it depends on your need. You can handle data binding with a form in any number of ways, some controls you can bind, some you wont, some will be bound only at times, etc etc etc. You can set binding levels in grouped controls, or for the form as a whole, or really in any way you see fit. .NET gives the felxibility to handle data in just about any way you can think of, so you have those kinds of options.
Well, there's my take on it. I spend quite some time looking for a "how to make a .NET program work like Access", and what it brought me around to was learning how to use ADO.NET to handle data, and how to do the data binding to the form. It really is two different worlds, and direct comparison from one to the other is difficult. If you picture yourself trying to re-build all of Access's internal workings, it becomes a little easier. At that point you can say ok, I want DAO-like functionality, let's start designing the classes required to make a data handler that acts like DAO does
Hope this helps some... sorry I wasn't able to provide more feedback on specific books for the subject. And, please take all this with a grain of salt... by no means to I claim to be proficient even in the slightest bit with .NET, but I thought this might help as I went through the same excersize some months ago.