[kfarmer]

Originally Posted by NatCh

Should I be looking for a LINQ class rather than an ADO class? Or something else? Since my exposure to ADO is what they "get to" at the end of a 5-day VBasic training, and an ADO book that I've not been able to find since our move last summer.

Okay, here's the deal:

The version of VB.NET that was just released includes LINQ. LINQ is a family of related libraries and language features that allow for .. Language Integrated Query (hence, "LINQ"). C#3 also has corresponding support, as do other langauges either released or in development.

So, if you take a class on VB9/VB.NET 2008, you'll almost certainly get an overview of VB's implementation of LINQ features: query syntax, extension methods, etc. Nearly *all* of the new features in the new releases of either VB or C# went to support LINQ in some way, though the features themselves stand on their own.

I said also that there are libraries, since the languge changes are meant to be used in conjunction with libraries that follow the LINQ pattern. .NET 3.5 is the release that contains the initial set of libraries: LINQ to Objects (queries over in-memory collections), LINQ to SQL (queries against SQL Server databases), LINQ to XML (a refined XML query and composition model). You can create your own providers by implementing the pattern, and that's what Oracle, etc are busy doing for release with LINQ to Entities, which is basically LINQ + ADO.NET + steroids.

You would do well by yourself, I think, to become familiar with LINQ in whatever langauge you choose. The concepts are pretty much language independent, as well as data store independent -- you use roughly the same code to query XML as you would an array, as you would a SQL database (or Active Directory, or Amazon, or whatever...).

That said, your employer may choose to stay with .NET 1.1 (god forbid) or .NET 2.0 (sigh), in which case LINQ isn't available, and ADO.NET would be the thing to learn. It's worth learning, anyway, since LINQ to SQL and LINQ to Entities are both based on it, and it mimics to a reasonable extent the relational model in memory, and you should have some foundation in this to appreciate what LINQ gives you, as well as to know how to cope when you have to step outside of LINQ to get something done.

ADO is something would use if you're using native VC++ (not using .NET).

So, it would depend on what you're using. The nice thing is that your employer's not going to stop you from learning any of this, and you can get all the tools for free: http://www.microsoft.com/express/

Originally Posted by NatCh

The unfortunate thing is that my degree was in electronics engineering. It gave me an excellent grounding for programming logic, but not so much on computer fundamentals on things like relational databases. Since Notes is the world's only non-relational DB system, I'm in for some schoolin' there too.

SQL is just set logic, pretty much, so I don't see why this should be a problem. You got an EE degree, which means you've done much more difficult things (IMHO) than writing database queries. ODEs, for one.

And there are other non-relational databases out there (eg, Matisse). Just maybe not as nameable.

Originally Posted by NatCh

I've toyed with the notion of going back for some or part of a CS degree, but so far, the logistics have been problematic.

My degree's in physics and astronomy, actually, and have considered going in for a Master's via an online program in Australia, but haven't had the time and money simultaneously. I've just been programming since 1982, and until a few years ago, that was a hobby.

I wouldn't worry about getting the CS degree if you've got actual work experience. Most good programmers I know taught themselves, actually.