>>I would have a preference for 'Blank' fields rather than 'Null' fields but maybe ny prference is musguided in the Dot Net scenario... I dont Know .<

Well, Gerard ... there's nothing wrong with null fields. I remember when I first started with .NET being a bit dismayed by that as well, but, if you think about it, null makes more sense than a blank or a zero, because null means data has never been entered. It just takes some getting to used to.

~~Bonnie


>Hi Magnus.
>
>Yes.. I was thinking along those lines .. just thought something might ave already been there.
>
>I wonder what other folk here do.. I've never had the problem upto now as I've alwayd developed in VFP and tended to use App Blank or similar, which automatically blanks the fields.
>
>I would have a preference for 'Blank' fields rather than 'Null' fields but maybe ny prference is musguided in the Dot Net scenario... I dont Know .
>
>Regards,
>
>Gerard
>
>
>
>>Hi Gerard,
>>
>>If you loop through the column collection and make sure you cover all the types there would not be any problem if you add a column later on.
>>
>>Why not write a little class file that takes a datarow as a param byref and initializes it with 'blank' data? Just a suggestion.
>>
>>>Hi Kevin.. thanks for your reply
>>>I suspected something like that would have to be done and was just 'hoping' there would have been an easier /shorter way to do it.
>>>
>>>The problem with this is that
>>>1) You have to cycle through each field and initialise it
>>>2) You have to test on the 'type' of eacj field if its to be done generically
>>>3) 2 Years on when you add an extra field to the table, it means having to
>>> go through each piece of code (in evry file in the APP and checking where you have 'added' a record
>>>
>>>.... Appe Blank was just so easy.... it did it all for you !!
>>>
>>>
>>>Regards
>>>Gerard
>>>
>>>
>>>
>>>>Just as a follow-up, you can also do this...
>>>>
>>>>
>>>>

>>>>DataRow DrNewRow = myTable.NewRow();
>>>>DrNewRow["firstname"] = ""
>>>>