Al,

>Interesting. My "fully qualified" version actually works, and it's what I built using IntelliSense when I first tried getting things to work. I only saw the "short" version later in an online post.<

That's because dt.Columns["dom_desc"].ToString( ) simply returns the column name, which is simply "dom_desc". =)

>That was my general impression - but I've seen code samples on the Web that seem (to me) to take the attitude "if it fails for any reason, do this" using try...catch. I can see that would be useful in some circumstances but in others it would just be lazy.<

The only time it makes sense to use a try/catch is if it's for something that you can't check for beforehand with an if. The try itself is no big deal if there are no exceptions thrown. It's the exception and the subsequent handling in the catch that's "expensive".

>Great idea - mind if I "borrow" that? ;)<

Be my guest! =)


>While we're talking about DB data types, do you know of any advantages in trying to work natively with SQL Server data types as outlined in http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconmappingnetdataproviderdatatypestonetframeworkdatatypes.asp ?<

Advantages? No. I can see plenty of disadvantages though. If you do that, you are definitely tied in to a specific back end. I would think that you'd have to do a lot of conversion back and forth between the types too (don't take that as gospel, since I've never even tried to use DB data types and wouldn't want to). There's absolutely nothing wrong (as far as I can see) with using the .NET Framework data types. Frankly, I don't see why anyone would want to do otherwise (although I'm sure there *must* be some good reason to do so that I'm not aware of).

~~Bonnie