>Al,
>
>You almost got it right. Try this:
>

>SomeType someValue = (SomeType)dt.Rows[SomeRowNumber][SomeColumnName or Index];
>

>
>Note that you have to do an explicit cast (since the DataRowColumn is merely an object). Also, beware of DBNull.Value. The above statement will crash if that column contains DBNull.Value. There are ways around this (typically by checking first before assigning).

That's terrific, thanks! By already knowing the answer I *think* you can infer this syntax from the example in the link Craig provided but it sure isn't clear. I looked far and wide in the MSDN docs and couldn't find anything like that.

This came up in the midst of wrestling with ASP.NET DropDownLists. I'm trying something like this:

// DataTable dt has 2 columns, dom_pkey (int) and dom_desc (string). Populated from SQL Server.
// ddl1 is a DropDownList
ddl1.DataSource = dt;
ddl1.DataTextField = "dom_desc"; // assumed shorthand for dt.Columns["dom_desc"].ToString( );
ddl1.DataValueField = "dom_pkey"; // assumed shorthand for dt.Columns["dom_pkey"].ToString( );

/* As an aside, it's interesting trying to read code samples that make use of these "shorthands", or
 implicit conversions or whatever their formal name is :) I find the fully-qualified versions easier to
 learn, and certainly more compatible with IntelliSense. Is there a general preference
 (i.e. "better practice") to use fully-qualified code, or "shorthand"? */

The default behaviour in the DDL seems to be that the int pkey values are being converted to strings. I don't know if a ddl.DataValueField can be anything other than a string; some Web posts I found imply it can but don't show how it's done. I've made it work casting back and forth to strings but it's a PITA, working natively with ints would be easier I think. Can you offer any advice?

It looks like Convert.IsDBNull( ) can be used to trap the DBNull.Value condition you pointed out. Is this sort of approach what's recommended, or is it more normal just to wrap an assignment in a try...catch?

Finally, if you're in "advice mode" what are your general thoughts re: NULL support in backend DBs? I'm working against SQL Server and getting it to do most of the grunt work by using views and sprocs. For a lot of what I'm doing now NULL support is "correct", in that the DB and app must be able to determine when a value hasn't ever been initialized. I could get around that by using default values in the DB to represent "null" but it's not quite the same.

In learning .Net it's amazing how many worms come out when you open an innocent-looking little can :) Well, at least I'm learning a lot < g >