>Al,
>
>Well, now you're getting into stuff I don't know that much about ... I have not worked much with WebForms, almost exclusively with WinForms. I did do some web stuff a few years ago when we were setting up some of the base classes (for both win and web), doing things like two-way databinding, but I haven't used it much at all since then and I've forgotten most of the details. I *do* know that the Web's DropDownList works differently than the Win's ComboBox, but I just don't know how much differently. In WinForms, a ComboBox's ValueMember does not get converted to a string if it's an int. I think maybe everything's treated as an object, but don't quote me on that. <g>
>
>>ddl1.DataTextField = "dom_desc"; // assumed shorthand for dt.Columns["dom_desc"].ToString( );
>
>What you're calling "shorthand" is not. The DataTextField is simply a string property of the DropDownList class that tells the what the column name is in the table that the control is being bound to. You can't specify it any other way.

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.

>
>>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?<
>
>NO NO NO ... never use a try/catch for something you can test with a simple if statement. Catch's are very costly!

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.

>I usually just compare like this:
>

>if (row["MyColumn"] != DBNull.Value)
>

>I've written my own method that I call GetNonNull that takes an object and assigns it a default. So, you'd call it something like this:
>

>int MyColumn = GetNonNull(row["MyColumn"], 0); // if I wanted to default it to zero
>

>This method has all kinds of overloads for the various types of defaults(int, string, date, etc.)

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

>
>>Finally, if you're in "advice mode" what are your general thoughts re: NULL support in backend DBs?
>
>I'm in favor of using NULLs. We use them in our DB.

I'm thinking that using NULLs will ultimately result in a less-bitten behind, so that's what I'm going to do.

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 ?