Learn VisualBasic.NET with Me

strict warning: Only variables should be passed by reference in /mnt/volume-sfo2-01/www/riceball.com/public/d/modules/book/book.module on line 559.

For the past week or so, I've been learning VB.NET (emphasis on .NET) to do what I thought a perl script and a little VBA was going to knock out. I'll be blogging a little bit on what I learn, as I learn it. To catch up on what's happened so far, see: /node/376 and the parent nodes.

Today, I learned about DataSets and schemas. They're intersting, and they really make life pretty difficult. A data set is an in-memory copy of a database that's located outside the app. That's the model of operation. The idea is that you can alter the data locally, then, the data set will be able to reconnect with the db, and update it. It makes programming a little harder.

The other thing I learned is that there are so many ways to access databases. MS is pushing ADO.NET, and MS SQL Server. ADO.NET talks well with SQL Server, and seems to do ok with Oracle too, but there isn't any Access support. For Access, you have to use OLE. This is a drag, because for my little app, even something like Access is overkill. But, since it's there, and it seemed to make life easier, I used it.

It was kind of hard getting the Access thing working, though. I thought that the db file would just sit out there, and a driver would let me query it. Indeed, that was possible, but there's a nicer mode, where you keep a copy of the db next to your app, and include it as part of the project. Then, VB will bundle a copy of the db with your app. (I haven't used VB in a while, you might have guessed.) ADO.NET supports both ways.

The first thing that stumped me was that the db wasn't persisting my data, when I was debugging. That's because it was creating a new copy of the db each time I started debugging. The way to test db persistence was to build it, and run it a couple times. It worked well.

The second thing was getting with the DataSet concept. I thought issuing a Refresh() on the DataGrid control would show my updates to the table. That didn't work. I had to issue a Fill() on the DataSet object, and specify the table I was filling from. This was done after every update, slowing things down considerably.

I was thinking of rewriting it to alter the dataset, but, ech. Too much work.

ADO.NET's datasets are impressive, technically, but, something about it bugs me. They seem to force you into making N+1-tier apps when you really only want N tiers. What I really want is to feel like the tiers are dropping away.

The new VB syntax for declaring objects is really hideous. It makes me want to port this to C#.

One really nice feature of VB2005 is that it has simple support for threading. That's what I'll work on tomorrow.