>Al,
>
>A constraint won't solve the problem. If it's an error on a form that causes the blank row. The constraint will merely disallow the bad data from making it to the tables. It would give a better "point of error" warning though, when the user is more capable of telling you an exact set of steps that caused the error to occur.
>
>If the blank row is happening outside the normal DBC workings, ie happened because of the power failure, the constraint still won't really solve it either.
>
>Don't get me wrong, constraints are good things, they aren't all powerful though.
>
>>On second thought, if by "data logic" you mean implementing some kind of table constraint so blank records aren't allowed at the *table* level, I think this truly is the fundamental solution - rather than fixing a data entry form. After all, someone could go in later and (assuming it's VFP) use raw VFP or attach via OLEDB and mess around with records. Or Access or Excel, for that matter.

I agree 100%. There are a number of layers that apply. It's a good illustration of all 3 tiers having rule obligations. Table, business, and UI logic is required, IMHO. Any one piece missing may cause problems down the road.