the main problem is value types cannot be null. use the new nullable
type. then check for DBNull being returned.
public class Project
{
uint? ProjectID;
string Description;
int? Status;
bool? Active;
}
p.ProjectID = dr.IsDBull(dr.GetOrdinal("ProjectID") : null ? (uint)
dr["ProjectID"];
i'd write a helper routine
-- bruce (sqlwork.com)
Hi Bruce,
I was hoping there was another way, but if the nullable data types are
what you're proposing, then that's what I'll go for.
I do have some more questions about it though... I think the answers
will very depending on whom I'm talking to, but that's just what I'm
after, so I can get an initial repository of paths to follow.
1. When using nullable types, would you recommend a best practice to
use nullable types only for the private fields inside the object
(those that get their data from the DB), and work with standard types
for the public properties?
For example:
private int? _status
public int Status
{
get
{
if (_status != DBNull)
return _status;
else
// return some default value
}
set
{
_status = value;
}
}
public void GetData()
{
//get DataReader object -- code omitted --
_status = (int?) dr["Status"];
}
2. what's your take on allowing NULL in the database? Thus far I've
always allowed it for fields that could be empty. But for fields that,
if empty, should take a default value, would it be better to set that
default value in the DB and set the field as NOT NULL. Or is it better
to provide the default value in the property set of the object class
(like in the example above)? I know there's no definitive answer to
this, but I'm looking for reasonings for and against nullable DB
fields.
-- Hans
> the main problem is value types cannot be null. use the new nullable
> type. then check for DBNull being returned.
[quoted text clipped - 58 lines]
>
> > -- Hans