>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.

I guess it depends on what the "problem" is. Way I read it, it's the presence of blank records in a table. A constraint would prevent this from happening again.

So, a badly written form breaks once in a while. Is this a bad thing? I'd say, a good prod for someone to fix it. A number of times I've implemented changes like this, and discovered *more* forms/procedures that were causing problems, not just the obvious one I'd found at first.

>
>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.

Well, if the power goes off, all bets are off anyways so that's not saying much. That's why paranoics use UPSs, real RDBMSs with transaction logs, etc. ;-)

>
>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.